Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - advanced mathematics for 3d polygons on the SMS

Reply to topic Goto page Previous  1, 2, 3, 4  Next
Author Message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Thu Mar 24, 2022 12:29 am
Kagesan wrote
maxxoccupancy wrote
And there are neither first person nor side scrolling shooters in the Homebrew section.


Here you go:
Pseudo-3D
Side scrolling

I doubt that will be of much help, though. Coding from scratch is probably a better idea.


Nice! It's not DOOM, but it's a start. Hopefully I can start tweaking the side scroller and see what I can come back with.
  View user's profile Send private message
  • Joined: 23 Jan 2010
  • Posts: 417
Reply with quote
Post Posted: Thu Mar 24, 2022 1:17 am
Quote
so we haven't seen too many (if any?) mind-blowing homebrew games that push the SMS to its limits in ways we never seen before. With that said, if you want to see these ideas in action you or someone you convince needs to write a demo to prove it's feasible. And it seems here nobody is interested in doing it for you, so you will need to just give it a try and see what your results are and see if they can be improved.

For me is mind-blowing see a Sonic Editor improved by Maxim. For me is mind-blowing have a new SMS editor by xfixium. For me is more important a Sonic Genesis hack done by Slogra, a Silver Valley, a Heroes of Demons, a Bara Buru (Games better than some official licensed). Is more impressive have hack mappers from bsittler, conversions from GG, MSX, Coleco to SMS. Dumps from Bock, patches made by Ichigo. Why? The people are hoping that SMS spit fire from all slots like as "pirotecnia". It´s is cool but you see these effects, showtime 1,2... 5 times and not is interesting more. There is a POC showing SMS pushed to limits? Nice! But we dont need to erase the merits of already done.
  View user's profile Send private message
  • Joined: 23 Jan 2010
  • Posts: 417
Reply with quote
Post Posted: Thu Mar 24, 2022 1:19 am
maxxoccupancy wrote
Kagesan wrote
maxxoccupancy wrote
And there are neither first person nor side scrolling shooters in the Homebrew section.


Here you go:
Pseudo-3D
Side scrolling

I doubt that will be of much help, though. Coding from scratch is probably a better idea.


Nice! It's not DOOM, but it's a start. Hopefully I can start tweaking the side scroller and see what I can come back with.

  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Thu Mar 24, 2022 4:20 am
segarule wrote
Quote
so we haven't seen too many (if any?) mind-blowing homebrew games that push the SMS to its limits in ways we never seen before. With that said, if you want to see these ideas in action you or someone you convince needs to write a demo to prove it's feasible. And it seems here nobody is interested in doing it for you, so you will need to just give it a try and see what your results are and see if they can be improved.

For me is mind-blowing see a Sonic Editor improved by Maxim. For me is mind-blowing have a new SMS editor by xfixium. For me is more important a Sonic Genesis hack done by Slogra, a Silver Valley, a Heroes of Demons, a Bara Buru (Games better than some official licensed). Is more impressive have hack mappers from bsittler, conversions from GG, MSX, Coleco to SMS. Dumps from Bock, patches made by Ichigo. Why? The people are hoping that SMS spit fire from all slots like as "pirotecnia". It´s is cool but you see these effects, showtime 1,2... 5 times and not is interesting more. There is a POC showing SMS pushed to limits? Nice! But we dont need to erase the merits of already done.


The Megadrive, GBA, PS1, NES, PC, etc, all got the chance to be pushed to their limits. But not the venerable SMS. Certainly, the new Sonic game looks and sounds amazing. In their parts, the HiFi and FMV demos are impressive. Yet we grew up playing the Master System and wondering what it's real limits were. When I saw Aladdin, Land of Illusion, and even Street Fighter II, I knew that the system still had some surprises left in it. This was an arcade board, after all.

The SMS was always capable of playing games that looked like this. Now that the power of a $200,000 Silicon Graphics workstation, full color, advanced illustration and 3D software is all available to us, you'd think people would be falling all over themselves to make games that look like this.

Well go back through this thread and count how many times someone posted some information to help make this possible. Two? Three? Now look at how many are telling the newb to come up with everything, that it can't be done, that others can do this for other systems, but not the SMS trying to do 3D graphics at lower resolution or fps.

  View user's profile Send private message
  • Joined: 09 Aug 2021
  • Posts: 106
Reply with quote
Post Posted: Thu Mar 24, 2022 1:09 pm
maxxoccupancy wrote
Now that the power of a $200,000 Silicon Graphics workstation, full color, advanced illustration and 3D software is all available to us

200000$ for an SGI workstation at the time it was actual - is not the same value as 200000$ now.
  View user's profile Send private message
  • Joined: 05 Jun 2010
  • Posts: 757
  • Location: Pennsylvania, USA
Reply with quote
Post Posted: Thu Mar 24, 2022 2:28 pm
segarule wrote
Quote
so we haven't seen too many (if any?) mind-blowing homebrew games that push the SMS to its limits in ways we never seen before. With that said, if you want to see these ideas in action you or someone you convince needs to write a demo to prove it's feasible. And it seems here nobody is interested in doing it for you, so you will need to just give it a try and see what your results are and see if they can be improved.

For me is mind-blowing see a Sonic Editor improved by Maxim. For me is mind-blowing have a new SMS editor by xfixium. For me is more important a Sonic Genesis hack done by Slogra, a Silver Valley, a Heroes of Demons, a Bara Buru (Games better than some official licensed). Is more impressive have hack mappers from bsittler, conversions from GG, MSX, Coleco to SMS. Dumps from Bock, patches made by Ichigo. Why? The people are hoping that SMS spit fire from all slots like as "pirotecnia". It´s is cool but you see these effects, showtime 1,2... 5 times and not is interesting more. There is a POC showing SMS pushed to limits? Nice! But we dont need to erase the merits of already done.


The Sonic Editor is a great effort by Maxim, but this is not a homebrew game.

I'm specifically referring to from-scratch games that are easily as good (ideally better) as commercially released games for the SMS.

Just for an example, Vector Pilot was a homebrew released about 12 years ago for the Vectrex and really showed off some great effects and it easily surpasses commercial games made for the Vectrex in it's heyday:

There are great effort here by developers and some cool games come out of the coding competition, but I don't think we've seen a grandiose, ultra-polished homebrew game for the SMS. I may be wrong, as I have not followed it as much in recent years. If I am wrong, then I apologize. And I do not mean to insult anyone here who has ever written a game, no matter how small or unfinished. I'm a coder myself and I understand the amount of work it takes to deliver a finished product.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Jun 2010
  • Posts: 757
  • Location: Pennsylvania, USA
Reply with quote
Post Posted: Thu Mar 24, 2022 2:57 pm
maxxoccupancy wrote
segarule wrote
Quote
so we haven't seen too many (if any?) mind-blowing homebrew games that push the SMS to its limits in ways we never seen before. With that said, if you want to see these ideas in action you or someone you convince needs to write a demo to prove it's feasible. And it seems here nobody is interested in doing it for you, so you will need to just give it a try and see what your results are and see if they can be improved.

For me is mind-blowing see a Sonic Editor improved by Maxim. For me is mind-blowing have a new SMS editor by xfixium. For me is more important a Sonic Genesis hack done by Slogra, a Silver Valley, a Heroes of Demons, a Bara Buru (Games better than some official licensed). Is more impressive have hack mappers from bsittler, conversions from GG, MSX, Coleco to SMS. Dumps from Bock, patches made by Ichigo. Why? The people are hoping that SMS spit fire from all slots like as "pirotecnia". It´s is cool but you see these effects, showtime 1,2... 5 times and not is interesting more. There is a POC showing SMS pushed to limits? Nice! But we dont need to erase the merits of already done.


The Megadrive, GBA, PS1, NES, PC, etc, all got the chance to be pushed to their limits. But not the venerable SMS. Certainly, the new Sonic game looks and sounds amazing. In their parts, the HiFi and FMV demos are impressive. Yet we grew up playing the Master System and wondering what it's real limits were. When I saw Aladdin, Land of Illusion, and even Street Fighter II, I knew that the system still had some surprises left in it. This was an arcade board, after all.

The SMS was always capable of playing games that looked like this. Now that the power of a $200,000 Silicon Graphics workstation, full color, advanced illustration and 3D software is all available to us, you'd think people would be falling all over themselves to make games that look like this.

Well go back through this thread and count how many times someone posted some information to help make this possible. Two? Three? Now look at how many are telling the newb to come up with everything, that it can't be done, that others can do this for other systems, but not the SMS trying to do 3D graphics at lower resolution or fps.


Just do it.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 879
  • Location: Spain
Reply with quote
Post Posted: Thu Mar 24, 2022 3:49 pm
Maraakate wrote

There are great effort here by developers and some cool games come out of the coding competition, but I don't think we've seen a grandiose, ultra-polished homebrew game for the SMS. I may be wrong, as I have not followed it as much in recent years. If I am wrong, then I apologize. And I do not mean to insult anyone here who has ever written a game, no matter how small or unfinished. I'm a coder myself and I understand the amount of work it takes to deliver a finished product.


I think the best homebrew that we've seen (totally original) is this one: https://www.smspower.org/Homebrew/FlightOfPigarus-SMS

If we also count hacks, apart from Alex Kidd 2 and 3, I really like this one: https://www.smspower.org/Hacks/AlexKiddInMiracleWorld-SMS-VoyageASorceressVacation-Mod
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Thu Mar 24, 2022 7:00 pm
toxa wrote
maxxoccupancy wrote
Now that the power of a $200,000 Silicon Graphics workstation, full color, advanced illustration and 3D software is all available to us

200000$ for an SGI workstation at the time it was actual - is not the same value as 200000$ now.


Yes, my $400 laptop now has the 5 GFlops performance that those old $200,000 Onyx systems had. We have literally free software that does most of the work that those $30,000 software packages had.

Now offer help and ideas for getting this project off the ground. I am learning how to use the DevKitSMS and best practices for the Z80, but that is a time consuming process.
  View user's profile Send private message
  • Joined: 26 Feb 2020
  • Posts: 13
Reply with quote
Post Posted: Thu Mar 24, 2022 7:09 pm
It might be worth looking into X for the gameboy. Using a slightly faster z80-related CPU than the SMS, it manages monochrome wireframes in a 16x11 tile window, with a screen update every other frame with one model in view, and as low as a half-screen update every six frames for when there's five or more models in view. Lots of speedups like trig lookup tables and using vertex loops instead of normals, and when i was disassembling it i couldn't find any further performance optimization in the 3D routines.
  View user's profile Send private message
  • Joined: 09 Aug 2021
  • Posts: 106
Reply with quote
Post Posted: Thu Mar 24, 2022 7:14 pm
maxxoccupancy wrote
Now offer help and ideas for getting this project off the ground. I am learning how to use the DevKitSMS and best practices for the Z80, but that is a time consuming process.

ideas? idea: make mario cart like this:
  View user's profile Send private message
  • Joined: 09 Aug 2021
  • Posts: 106
Reply with quote
Post Posted: Thu Mar 24, 2022 7:22 pm
2Tie wrote
Using a slightly faster z80-related CPU than the SMS, it manages monochrome wireframes in a 16x11 tile window, with a screen update every other frame with one model in view, and as low as a half-screen update every six frames for when there's five or more models in view.

DMG cpu is not faster and not very related to z80, it is more closer to 8080. Game boy has very different architecture and code optimization patterns are different as well.

btw, there is also better game boy game example - "Faceball 2000".
  View user's profile Send private message
  • Joined: 25 Feb 2006
  • Posts: 864
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Thu Mar 24, 2022 8:36 pm
2Tie wrote
It might be worth looking into X for the gameboy. Using a slightly faster z80-related CPU than the SMS, it manages monochrome wireframes in a 16x11 tile window, with a screen update every other frame with one model in view, and as low as a half-screen update every six frames for when there's five or more models in view. Lots of speedups like trig lookup tables and using vertex loops instead of normals, and when i was disassembling it i couldn't find any further performance optimization in the 3D routines.


Interesting; would there be a disassembly available?

toxa wrote
2Tie wrote
Using a slightly faster z80-related CPU than the SMS, it manages monochrome wireframes in a 16x11 tile window, with a screen update every other frame with one model in view, and as low as a half-screen update every six frames for when there's five or more models in view.

DMG cpu is not faster and not very related to z80, it is more closer to 8080. Game boy has very different architecture and code optimization patterns are different as well.

btw, there is also better game boy game example - "Faceball 2000".


There's already a version of "Faceball 2000" for Game Gear.


Another game that uses awesome 3D effects on the original Game Boy is Race Drivin':


maxxoccupancy wrote
toxa wrote
maxxoccupancy wrote
Now that the power of a $200,000 Silicon Graphics workstation, full color, advanced illustration and 3D software is all available to us

200000$ for an SGI workstation at the time it was actual - is not the same value as 200000$ now.


Yes, my $400 laptop now has the 5 GFlops performance that those old $200,000 Onyx systems had. We have literally free software that does most of the work that those $30,000 software packages had.

Now offer help and ideas for getting this project off the ground. I am learning how to use the DevKitSMS and best practices for the Z80, but that is a time consuming process.


Since you're still starting, and this is a POC, anyway, you could start with some simple rail shooter, like "The Downward Spiral" for GB:


I also made a raycaster prototype for GBC many years ago; 90% of its code is in C:
https://github.com/haroldo-ok/really-old-stuff/tree/master/gameboy
  View user's profile Send private message Visit poster's website
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
nVidia FP8
Post Posted: Fri Mar 25, 2022 7:08 am
nVidia is also using two different types of 8-bit floating point formats:
e4m3
e5m2

The sign eats up one of the bits, and they have to use different numbers for different ranges. Still, for LookUp Tables using 8-bit inputs:
A8 * B8 = C8
yields a table of just 64KB, easy enough to fit on a 4MB ROM cart.

LookUp Tables for more complex calculations like Reciprocal Square Root are only 256 bytes of results. Likewise,

60,000 cycles per frame is about 10,000 instructions per frame. The conventional 3D graphics pipeline is, IIRC, 46 floating point operations per vertex, so that's
64 sprite-textures * 46 LookUps = 2500 fp operations per frame

If a sprite-texture is going to be placed at each of 64 vertexes to form shapes (using the Painter's Algorithm and giving priority to each sprite based on the distance found from DDA raycasting), we would still have enough Z80A time to handle VRAM updates, HiFi audio, line interrupts for the 3D effects for the background, and processing input from the player.

This is one approach to raycasting, though it's multiply and square root intensive.


  View user's profile Send private message
  • Joined: 12 Dec 2021
  • Posts: 43
  • Location: Melbourne, Australia
Reply with quote
Post Posted: Fri Mar 25, 2022 8:51 am
I'm very much still a beginner with the SMS, but I think you've perhaps put enough interesting theory out there, and it's time to put it into practise. Instead of considering theoretical things that could be possible, have a go. Write some code. See what you can make! It's fun, and the people here are super supportive. But you gotta take that first step and put code to cart.
  View user's profile Send private message
  • Joined: 09 Aug 2021
  • Posts: 106
Reply with quote
Post Posted: Fri Mar 25, 2022 10:18 am
maxxoccupancy wrote
60,000 cycles per frame is about 10,000 instructions per frame. The conventional 3D graphics pipeline is, IIRC, 46 floating point operations per vertex, so that's
64 sprite-textures * 46 LookUps = 2500 fp operations per frame

your calculations are wrong. forget about floating point. you can not use it if you want to achieve any performance. all "3d" must be performed on the scaled integers.
  View user's profile Send private message
  • Joined: 25 Feb 2006
  • Posts: 864
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Fri Mar 25, 2022 10:40 am
maxxoccupancy wrote
nVidia is also using two different types of 8-bit floating point formats:
e4m3
e5m2

The sign eats up one of the bits, and they have to use different numbers for different ranges. Still, for LookUp Tables using 8-bit inputs:
A8 * B8 = C8
yields a table of just 64KB, easy enough to fit on a 4MB ROM cart.

LookUp Tables for more complex calculations like Reciprocal Square Root are only 256 bytes of results. Likewise,

60,000 cycles per frame is about 10,000 instructions per frame. The conventional 3D graphics pipeline is, IIRC, 46 floating point operations per vertex, so that's
64 sprite-textures * 46 LookUps = 2500 fp operations per frame

If a sprite-texture is going to be placed at each of 64 vertexes to form shapes (using the Painter's Algorithm and giving priority to each sprite based on the distance found from DDA raycasting), we would still have enough Z80A time to handle VRAM updates, HiFi audio, line interrupts for the 3D effects for the background, and processing input from the player.

This is one approach to raycasting, though it's multiply and square root intensive.


I believe you're falling into the trap of premature optimization:
https://stackify.com/premature-optimization-evil/

No matter how many times you try to speed up your 3D calculations, they won't really be your main bottleneck, in the first place.

Your bottleneck would be primarily be the VDP.

Remember that the VDP is not designed to render polygons by hardware; you will need to draw them via software.

Also, since this is a POC, don't shy away from using C; just trying to make the VDP display what you want, no matter how slow, will be enough of a challenge.

If you want to test the viability of your project, start doing something simple:
- Render an animated zooming sprite; no 3D, that can come later; just plain scaling; if you can't make this fast, 3D will be even slower;
- Render a single 2D triangle with random vertices, then keep randomly changing its vertices and redrawing it, to see how fast it goes; if you cannot draw a 2D triangle fast, you won't have any chance with 3D triangles to begin with.
  View user's profile Send private message Visit poster's website
  • Joined: 23 Jan 2010
  • Posts: 417
Reply with quote
Post Posted: Fri Mar 25, 2022 11:13 am
This can be useful (see at 2:37s):


Author´s explanation:
Just a side note: my "player" has all tiles precomputed and stored in ROM and/or in VRAM
The sole useful thing I see for a 3d polygonal game is that my technique allows double buffering in screen 2 on a plain msx1
Here:
https://www.msx.org/forum/msx-talk/software/msx-vs-spectrum-3d-graphics?page=1
  View user's profile Send private message
  • Joined: 05 Jun 2010
  • Posts: 757
  • Location: Pennsylvania, USA
Reply with quote
Post Posted: Fri Mar 25, 2022 12:53 pm
darkowl wrote
I'm very much still a beginner with the SMS, but I think you've perhaps put enough interesting theory out there, and it's time to put it into practise. Instead of considering theoretical things that could be possible, have a go. Write some code. See what you can make! It's fun, and the people here are super supportive. But you gotta take that first step and put code to cart.


This guy just wants someone else to do it. Multiple people have suggested he start writing some code, but clearly he does not do it. It's fine to hypothesize and get some ideas, but this conversation has been going around in circles.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Fri Mar 25, 2022 1:43 pm
haroldoop wrote
maxxoccupancy wrote
nVidia is also using two different types of 8-bit floating point formats:
e4m3
e5m2

The sign eats up one of the bits, and they have to use different numbers for different ranges. Still, for LookUp Tables using 8-bit inputs:
A8 * B8 = C8
yields a table of just 64KB, easy enough to fit on a 4MB ROM cart.

LookUp Tables for more complex calculations like Reciprocal Square Root are only 256 bytes of results. Likewise,

60,000 cycles per frame is about 10,000 instructions per frame. The conventional 3D graphics pipeline is, IIRC, 46 floating point operations per vertex, so that's
64 sprite-textures * 46 LookUps = 2500 fp operations per frame

If a sprite-texture is going to be placed at each of 64 vertexes to form shapes (using the Painter's Algorithm and giving priority to each sprite based on the distance found from DDA raycasting), we would still have enough Z80A time to handle VRAM updates, HiFi audio, line interrupts for the 3D effects for the background, and processing input from the player.

This is one approach to raycasting, though it's multiply and square root intensive.


I believe you're falling into the trap of premature optimization:
https://stackify.com/premature-optimization-evil/

No matter how many times you try to speed up your 3D calculations, they won't really be your main bottleneck, in the first place.

Your bottleneck would be primarily be the VDP.

Remember that the VDP is not designed to render polygons by hardware; you will need to draw them via software.

Also, since this is a POC, don't shy away from using C; just trying to make the VDP display what you want, no matter how slow, will be enough of a challenge.

If you want to test the viability of your project, start doing something simple:
- Render an animated zooming sprite; no 3D, that can come later; just plain scaling; if you can't make this fast, 3D will be even slower;
- Render a single 2D triangle with random vertices, then keep randomly changing its vertices and redrawing it, to see how fast it goes; if you cannot draw a 2D triangle fast, you won't have any chance with 3D triangles to begin with.


The intent is not to scale sprite-textures, but just to place them. The VDP only displays background tiles and sprites based on the values in the table. It's the Z80A that has to calculate those locations.

I'm not proposing to draw triangles, but just place the sprite-textures frame by frame.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Fri Mar 25, 2022 1:47 pm
toxa wrote
maxxoccupancy wrote
60,000 cycles per frame is about 10,000 instructions per frame. The conventional 3D graphics pipeline is, IIRC, 46 floating point operations per vertex, so that's
64 sprite-textures * 46 LookUps = 2500 fp operations per frame

your calculations are wrong. forget about floating point. you can not use it if you want to achieve any performance. all "3d" must be performed on the scaled integers.


See the earlier posts about LookUp Tables. Each calculation only requires a single load from the game ROM.
  View user's profile Send private message
  • Joined: 25 Feb 2006
  • Posts: 864
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Fri Mar 25, 2022 1:59 pm
maxxoccupancy wrote

The intent is not to scale sprite-textures, but just to place them. The VDP only displays background tiles and sprites based on the values in the table. It's the Z80A that has to calculate those locations.

I'm not proposing to draw triangles, but just place the sprite-textures frame by frame.


Good, then you don't need lookup tables, nor do you need anything 3D at this point in time.

You could follow those steps:
1- Just create a ROM that displays a single sprite on screen;
2- Using any paint program, create scaled versions of that same sprite image;
3- Now, modify the ROM created on step 1 to display the scaled sprites created on step 2 consecutively on screen.

That would be a good start. You could even do this in plain C, since it's just a POC, and it is just a single scaled sprite.

If you can't take this first step; talking about custom FP formats and lookup tables will be pointless.
  View user's profile Send private message Visit poster's website
  • Joined: 04 Jul 2010
  • Posts: 539
  • Location: Angers, France
Reply with quote
Post Posted: Fri Mar 25, 2022 2:07 pm
You've only forget some "simple things", like banks are 16k only.
Switching/restoring banks takes time (nothing is free), even if it's only few cycles/instructions.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Fri Mar 25, 2022 4:44 pm
ichigobankai wrote
You've only forget some "simple things", like banks are 16k only.
Switching/restoring banks takes time (nothing is free), even if it's only few cycles/instructions.


For A*B, where each is 8 bits in width, why can't the upper two bits of A be used to select which of four banks to use?

Or, since one bit of each is a sign bit, you could even pull the sign from each FP8 number (leaving seven bits for each) and use that to select which of the four banks to read from.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Fri Mar 25, 2022 4:50 pm
haroldoop wrote
maxxoccupancy wrote

The intent is not to scale sprite-textures, but just to place them. The VDP only displays background tiles and sprites based on the values in the table. It's the Z80A that has to calculate those locations.

I'm not proposing to draw triangles, but just place the sprite-textures frame by frame.


Good, then you don't need lookup tables, nor do you need anything 3D at this point in time.

You could follow those steps:
1- Just create a ROM that displays a single sprite on screen;
2- Using any paint program, create scaled versions of that same sprite image;
3- Now, modify the ROM created on step 1 to display the scaled sprites created on step 2 consecutively on screen.

That would be a good start. You could even do this in plain C, since it's just a POC, and it is just a single scaled sprite.

If you can't take this first step; talking about custom FP formats and lookup tables will be pointless.


I've got Pro Motion NG open and will probably be using that to draw the sprites.

The scaling method that I suggested in this thread, though, uses 2-4 leafy sprites that gradually move apart as the object gets closer, placed over a leafy trunk on a background tile.

What will you give me if I make it look pretty?
  View user's profile Send private message
  • Joined: 26 Feb 2020
  • Posts: 13
Reply with quote
Post Posted: Fri Mar 25, 2022 4:59 pm
toxa wrote
DMG cpu is not faster and not very related to z80, it is more closer to 8080.

my bad, i made sure to look up the clock speeds for both systems before posting that but if that's not their comparable performance speeds then i don't know what would be.
i've also found the sm83 to be more similar to the z80 than the i8080 when making homebrew and romhacks for the three of them, what with the relative jumps and the $CB prefixed opcodes. shrug.

haroldoop wrote
Interesting; would there be a disassembly available?

yessiree https://github.com/2Tie/X-disasm
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Fri Mar 25, 2022 5:22 pm
2Tie wrote
toxa wrote
DMG cpu is not faster and not very related to z80, it is more closer to 8080.

my bad, i made sure to look up the clock speeds for both systems before posting that but if that's not their comparable performance speeds then i don't know what would be.
i've also found the sm83 to be more similar to the z80 than the i8080 when making homebrew and romhacks for the three of them, what with the relative jumps and the $CB prefixed opcodes. shrug.

haroldoop wrote
Interesting; would there be a disassembly available?

yessiree https://github.com/2Tie/X-disasm


Not to put out my own fire, but merging background tiles on the SMS is so slow that Street Fighter II only runs at about 10-11fps because of it. So a strictly DOOM/Wolfenstein rendering is probably not realistic, even for a tiny window.

For anyone who missed it, what I'm suggesting is a different way of rendering fast--but grainy and jagged--3D using the 64 sprites to cover small areas in place of the triangles and rectangles in the conventional 3D environment. This means that the object or objects would be limited to about 1/12th of the screen.

At best, imagine one fighter from Virtua Fighter, or just the track alone (and some objects above the horizon) in Virtua Racing.
  View user's profile Send private message
  • Joined: 09 Aug 2021
  • Posts: 106
Reply with quote
Post Posted: Fri Mar 25, 2022 8:14 pm
Last edited by toxa on Fri Mar 25, 2022 8:29 pm; edited 1 time in total
maxxoccupancy wrote
See the earlier posts about LookUp Tables. Each calculation only requires a single load from the game ROM.

There is no such thing as "single load" for a floating point value. Speaking about floating point standard types - single is 4 bytes and double is 8 bytes. Even 16-bit value can not be loaded indirectly using single instruction, because Z80 lacks ld r16, (r16) instruction.16-bit floating point accuracy is not anyhow tolerable anyway.
  View user's profile Send private message
  • Joined: 09 Aug 2021
  • Posts: 106
Reply with quote
Post Posted: Fri Mar 25, 2022 8:22 pm
2Tie wrote
i've also found the sm83 to be more similar to the z80 than the i8080 when making homebrew and romhacks for the three of them, what with the relative jumps and the $CB prefixed opcodes. shrug.

difference with z80 is huge. lack of registers and shadow set, lack of block instructions, absolutely different interrupt system, and so on.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Fri Mar 25, 2022 10:11 pm
toxa wrote
maxxoccupancy wrote
See the earlier posts about LookUp Tables. Each calculation only requires a single load from the game ROM.

There is no such thing as "single load" for a floating point value. Speaking about floating point standard types - single is 4 bytes and double is 8 bytes. Even 16-bit value can not be loaded indirectly using single instruction, because Z80 lacks ld r16, (r16) instruction.16-bit floating point accuracy is not anyhow tolerable anyway.


As I said, nVidia seems to be happy using FP8 numbers, and those work for most calculations in 3D graphics. Granted, nVidia has some tools for figuring out where they need FP16 and where they need FP32. The fact that they can get away with 8 bit fp numbers for most of their calculations on 8 megapixel display implies that these same numerics could be used on 256x192 displays for all calculations. When additional accuracy is needed, fp has a few more tricks where all numbers can be rounded up (toward +/- infinity) or down toward +/- zero and then average the result to reduce error.

The 3 bits of mantissa produce 4 bits of fraction, and that is sufficient in most cases for a single floating point operation (sin, cos, recip square root, multiply-add, etc). It only becomes a problem when you have to string together many fp operations that the loss of precision becomes a noticeable problem.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14688
  • Location: London
Reply with quote
Post Posted: Fri Mar 25, 2022 11:38 pm
Great, let us know how you get on with that fp8 demo.
  View user's profile Send private message Visit poster's website
  • Joined: 17 Jan 2020
  • Posts: 118
  • Location: Brisbane, AU
Reply with quote
Post Posted: Sat Mar 26, 2022 2:47 am
I spent a fair bit of time looking into to doing 3D on the SG-1000. It's the reason I originally wrote the "lines" demo. Here's a couple of demos.

I've written 4 graphical demos for 3D graphics:

Asteroids 3D. The 3D objects from Elite rotating around on the screen, with backface culling


Maze 3D. The first level of Wolfenstein 3D using ray casting


Road 3D. The first part of Harddrivin using a proper 3D environment


Asteroids. Asteroids using lines, as a feasibility test for using vector graphics.


About 70% of the time is spent rendering lines.

Line rendering is an expensive operation. You might reasonably think that writing to the vdu is the bottleneck, but actually it’s not. While writing to the vdu is slow, each write to the vdu actually requires a lot of calculations.

The line rendering is broken into four parts:

- Looping through each pixel and calculating the x and y
- Determining the line segment bits and writing this to the vdu (pixel table)
- Calculating which tile where on the screen is modified, updating the tile used.
- Clearing the modified tiles to be updated again next frame

Each of these steps isn’t large or long, but for the several thousands of pixels it takes to render a 3D object on the screen, these all quickly add up.

16bit integer maths is used throughout. The screen is 256 bits wide, so the values must be this wide at least. However 16bits x 16bits = 32bits, so multiplications typically need to be at least 24bits.

Typically about 20% is spent in doing the multiplications. 3D maths is mostly about multiplying numbers. It may seem like the most expensive part, but it’s not. It’s high, but optimising 20% only gives so much.

Another component is managing all the 3D data, the points, or the cells etc. Maze3D using ray casting must check the type of each cell in the maze, and this is a slow operation on the Z80. Asteroids3D builds all the objects from points and lines, which need to be connected at run time.

Don’t underestimate the amount of time spent in the code in between all these operations. Simply calling functions in the Z80 is slow, using the stack, so all processing required to call functions on all this data being processed adds up as well.

Typically the demos run around 3 frames per second, which isn’t enough to create an enjoyable game experience. I gave up when I realised this and the reason these are only demos, not completed games.

Maze 3D probably could be done using tiles instead of lines, but even in the best case this probably would only add a few fps to the game, since rendering is only about 50% of the processing time.

All these demos are in mode 2, mostly because I’m interested in writing SG-1000 games. Using mode 4 has the disadvantage of having pixels are 4bpp instead of 1bpp in mode 2. However, the 4K ram on the Master System would allow double buffering, which would be advantageous.

I've added the profiles for the games to give you an idea of the break down on the processing of the games.

Below are the collapsed profile, which gives an idea of the high level usage (calculations vs rendering)


Asteroids 3D, Road3D, Maze 3D and Asteroids summary profiles

Below are the expanded profiles, for those who may interested in the details of the processing:


Asteroids 3D, Road3D, Maze 3D and Asteroids expanded profiles
Asteroids-SG-1.00.zip (17.37 KB)
Maze3d-SG-1.00.zip (14.69 KB)
Road3D-SG-1.00.zip (18.57 KB)

  View user's profile Send private message Visit poster's website
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Sat Mar 26, 2022 5:37 am
Thank you so much. I've been looking for details like this. I'm fine with using different display modes, though I've been thinking of sticking with Mode 4 and prerendering sprites to use as textures. Of course, even using 8x16 sprites, only an area of 64x128 could cover the screen.

The SMS has 8KB of RAM, but that's more effective because the system usually reads program and tiles directly from game ROM, and, IIRC, about 2KB of tile tables are kept in the 16KB of VRAM.

I've even thought of using all background tiles, then having every possible combination of pre-rendered background tile to build up an image.

Right now, working with the limits of the VDP hardware, I feel like the three best options are:
1. Overhead shooter similar to Thunderblade arcade
2. Side scrolling shooter like R-Type (parallax scrolling)
3. Race track game similar to Outrun or Super Monaco GP

In all three cases, we'd have to default to traditional SEGA 3D effects used on the SMS in other 3D-like games, but with a few more tricks to create the illusion of fast movement and a 3D world.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Sat Mar 26, 2022 6:07 am
And I came to the same conclusion that you did about Wolfenstein 3D using raycasting and using the VDP to draw tiles. In fact, someone else here with more experience on the SMS came to the same conclusion.

The three different 3D effects here could be used to generate background tile maps for the walls that would be convincing enough. Instead of animated sprites, many different background tiles could be prerendered then lined up in the 32x28 tile grid to give very jagged walls. I'd even thought of using another group of sprite tiles for angles where the walls intersect with the ceiling and floor, just to create that smooth line.


For DOOM on the SNES, a simple dithered ceiling and floor were used that remained static. They also used LookUp Tables for fast mathematics on the system.

Such a demo would resemble a Wolfenstein/DOOM port, though stairs, watery areas, and perhaps even elevators would be difficult or even impossible given the hardware limitations of the SMS.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Sat Mar 26, 2022 6:48 am
And the many tricks needed to get a Doom-like maze playing on the 1.2 MIPS Genesis. The Z80 is only capable of 520 KIPS and has far less memory to work with. Nevertheless, we'd have to use the same mirroring and many of the same techniques to get anywhere near 24fps on the 8-bit little brother.

And I'm pretty sure that we'd have to use background tiles--not "strips"--for everything to make this happen.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3763
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Sat Mar 26, 2022 9:24 am
under4mhz wrote
I spent a fair bit of time looking into to doing 3D on the SG-1000. It's the reason I originally wrote the "lines" demo.


Thanks for your very interesting post and the detailed explanations! Lots of information to base our expectancy when speaking about 3D.

I wonder if you could attach the images to the post for preservation (or maybe the fairy will magically fix it...?)
  View user's profile Send private message Visit poster's website
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Sat Mar 26, 2022 6:52 pm
My point being is that, if FP8 works most of the time with 1-2% losses in accuracy, then a custom SMS floating point standard could work also:
-8 bit exponent, including the sign, with compares and exponent adds handled on the Z80A
-7 bit mantissa (with implied '1,' as with IEEE 754/854) using a 7x7 LookUp Table for anything more complicated than FP add or subtract

That would produce 16KB LookUp Tables for fpMul, fpDiv, fpSine, fpCosine, fpSquareRoot, fpRecipSqRoot, and other functions. Only a few operations would also require that the exponent also be sent to its own LookUp Table for a result. I would estimate that perhaps 10 banks of memory (160KB) could be used to handle all of the floating point work for the truncated 3D graphics pipeline that I'm suggesting.

This would essentially be just the upper 15 bits IEEE 754 single precision number, and the mathematics could be done very quickly, since we're only calculating the locations for 64 sprite-textures to be read and displayed by the VDP.

If we tried to go full screen, then that means selecting which of the pre-rendered 448 background tiles goes into each of the 32x28 tile locations. Alternately, we could use color cycling and have the Z80A calculate which of five 3-color tiles to display--though that choice is then applied to every tile in a horizontal line, forcing Wolfenstein/Doom style graphics.
  View user's profile Send private message
  • Joined: 01 Feb 2014
  • Posts: 849
Reply with quote
Post Posted: Sun Mar 27, 2022 8:07 am
It seems you still haven't made up your mind what exactly you want to achieve, just that it's supposed to be something that's vaguely 3D-ish. However, defining a clear goal is the very first step if you want to get somewhere.

Outside of a demo context, effects are not an end in itself, so if you want to put them in the context of a game, you need to make sure that the game side of your project works first and foremost.

You need to get away from those Coding Secrets videos. The techniques presented there are not universally reusable and taylored very specifically to the Mega Drive. The Master System has a very different architecture, which you should be aware of by now after several people have explained it to you in detail, but which you choose to ignore.

Of the effects shown, the floor could be easily done on the SMS, but the furniture would need to use up a lot of sprites you'd probably want to use elsewhere for more game-relevant things, like, you know, displaying a player character or some enemies.
Those 3D walls? Forget it. The best you can hope for is something like the dungeons in Phantasy Star, but those are basically prerendered animations, and even those only work at the speed required through some crazy optimizations one of which is the sparseness of their design.

But having this conversation go around in yet another circle is pointless. Since you seem determined to think that us naysayers are just to narrow-minded and don't know what we're talking about while you have it all figured out, I suggest you get to work and prove us wrong. That code's not going to write itself, and I think it's clear by now that no one else is willing to do it for you either.

In the meantime, "we" are eagerly waiting for your results. Good luck!
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Sun Mar 27, 2022 6:26 pm
Kagesan wrote
It seems you still haven't made up your mind what exactly you want to achieve, just that it's supposed to be something that's vaguely 3D-ish. However, defining a clear goal is the very first step if you want to get somewhere.

Outside of a demo context, effects are not an end in itself, so if you want to put them in the context of a game, you need to make sure that the game side of your project works first and foremost.

You need to get away from those Coding Secrets videos. The techniques presented there are not universally reusable and taylored very specifically to the Mega Drive. The Master System has a very different architecture, which you should be aware of by now after several people have explained it to you in detail, but which you choose to ignore.

Of the effects shown, the floor could be easily done on the SMS, but the furniture would need to use up a lot of sprites you'd probably want to use elsewhere for more game-relevant things, like, you know, displaying a player character or some enemies.
Those 3D walls? Forget it. The best you can hope for is something like the dungeons in Phantasy Star, but those are basically prerendered animations, and even those only work at the speed required through some crazy optimizations one of which is the sparseness of their design.

But having this conversation go around in yet another circle is pointless. Since you seem determined to think that us naysayers are just to narrow-minded and don't know what we're talking about while you have it all figured out, I suggest you get to work and prove us wrong. That code's not going to write itself, and I think it's clear by now that no one else is willing to do it for you either.

In the meantime, "we" are eagerly waiting for your results. Good luck!


Are you implying motives? I keep proposing different ways to overcome the lack of floating point hardware on the SMS, trying to get feedback from developers who've worked with the hardware already.

For example, a floating point number that is 8 bit exponent only, but putting the decimal point 2-3 positions above the Unit in the Last Place, would provide for very fast multiplies and divides. You can simply add or subtract the exponents in the Z80A's ALU to carry out very fast multiplies and adds. There are lots of other complex mathematics that can be done using exponent only mathematics, also.

Telling someone who has no experience writing games for the SMS to "just do it yourself" doesn't get us one step closer to a demo. I am on this forum asking for feedback and input. A large project like building a race track game requires more than just one SMS noob sitting down and figuring out everything for himself.

I'm not going to ignore the Coding Secrets videos because more than half of the techniques mentioned can also be made to work on the SMS. Animation sprites, animated backgrounds, audio samples, parallax scrolling, color cycling, and even changing pallets to simulate sunsetting and shadows can all be done on the SMS.

Help or don't. But don't cast aspersions.
  View user's profile Send private message
  • Joined: 09 Aug 2021
  • Posts: 106
Reply with quote
Post Posted: Mon Mar 28, 2022 6:58 am
maxxoccupancy wrote
For example, a floating point number that is 8 bit exponent only, but putting the decimal point 2-3 positions above the Unit in the Last Place, would provide for very fast multiplies and divides. You can simply add or subtract the exponents in the Z80A's ALU to carry out very fast multiplies and adds. There are lots of other complex mathematics that can be done using exponent only mathematics, also.

Stop blabbing, write such div/mul routines with a few unit-tests for z80, we will look and profile. Will be quite obvious benchmark.
  View user's profile Send private message
  • Joined: 01 Feb 2014
  • Posts: 849
Reply with quote
Post Posted: Mon Mar 28, 2022 7:35 am
maxxoccupancy wrote
Telling someone who has no experience writing games for the SMS to "just do it yourself" doesn't get us one step closer to a demo. I am on this forum asking for feedback and input.


This forum is traditionally very welcoming to new members, and most of us here are more than willing to help anyone along who decides to embark on the big adventure that is Sega 8 bit development. You can always count on even the most stupid noob question getting answered quickly and respectfully. I know it because I've been there, too, and I asked a ton of these questions back when I started out.

However, not once has it occured to me to ask for someone else to take my ideas and make them a reality, and I don't think that's something you should expect either.

You've recieved plenty of feedback and input by now, you just don't like it, because people keep telling you that your assumptions are overly optimistic and are skeptical that putting them to use can lead to worthwhile results.

There's no way around it. If you want to see it happen, you need to start writing some code. We'll gladly help you with any questions that may come up, but we'll not do the work for you.
  View user's profile Send private message
  • Joined: 04 Jul 2010
  • Posts: 539
  • Location: Angers, France
Reply with quote
Post Posted: Mon Mar 28, 2022 7:52 am
Quote
Animation sprites, animated backgrounds, audio samples, parallax scrolling, color cycling, and even changing pallets to simulate sunsetting and shadows can all be done on the SMS.


Every advanced coder here already kown how to achieve this sort of simple things. Effects are just what they are, effects.

Take time reading documentations, dissassembling roms, trying things, learning C or better ASM... It will take time, certainly years, as no one will do this for you.

Came back when you'll have really start coding something.
Many of us will help if you've got questions.

The most interesting part is the path, not the end.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Mon Mar 28, 2022 5:39 pm
ichigobankai wrote
Quote
Animation sprites, animated backgrounds, audio samples, parallax scrolling, color cycling, and even changing pallets to simulate sunsetting and shadows can all be done on the SMS.


Every advanced coder here already kown how to achieve this sort of simple things. Effects are just what they are, effects.

Take time reading documentations, dissassembling roms, trying things, learning C or better ASM... It will take time, certainly years, as no one will do this for you.

Came back when you'll have really start coding something.
Many of us will help if you've got questions.

The most interesting part is the path, not the end.


I don't consider this a noob-style project, but a group project. Group projects require input form the group.

As an individual, I can add yet another Alex Kidd style side scroller to the list of homebrew games, but that is not something that excites me.

Working with others, I can contribute to the Street Fighter II game and Doom port to the 32X.

Even John Carmack on John Burton had teams with whom they worked. 3D graphics is not a one man show.
  View user's profile Send private message
  • Joined: 04 Jul 2010
  • Posts: 539
  • Location: Angers, France
Reply with quote
Post Posted: Mon Mar 28, 2022 6:33 pm
Please, don't try to make me laugh.
A "group project" need people and also a real project.

For the moment you're not even able to correctly edit tiles.
  View user's profile Send private message
  • Joined: 09 Aug 2021
  • Posts: 106
Reply with quote
Post Posted: Mon Mar 28, 2022 7:33 pm
maxxoccupancy wrote
I don't consider this a noob-style project, but a group project. Group projects require input form the group.

Who are in your group?
  View user's profile Send private message
  • Joined: 07 Mar 2021
  • Posts: 55
Reply with quote
Post Posted: Mon Mar 28, 2022 7:41 pm
maxxoccupancy, the SMS is a console ahead of its time, but it just wasn't designed for 3D.

Some very talented programmers (and as it has been said you had some on this topic) can exploit the capacities of the machine at best but without performing miracles.

Experienced people will never commit to a project they deem unfeasible.

The last published prototype of Basketball Nightmare clearly shows the limits of the exercise of 3D on SMS : Adding more gameplay to a similar graphical experience seems complicated to me.

Or else you have to move towards something similar to the phantasy star dungeons. very complicated.

People here have shown kindness by telling you to experiment. Thus you will understand the limits of a machine which remains a pleasure to program.
  View user's profile Send private message
  • Joined: 23 Aug 2009
  • Posts: 213
  • Location: Seattle, WA
Reply with quote
Post Posted: Mon Mar 28, 2022 9:22 pm
What's your high-level main loop (including VBL) look like? I find that detailing out the control and data flows helps me validate what I'm trying to achieve. Once the main loop is confirmed, then we can double click into a few of the stages of that main loop to go deeper into validating.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Mon Mar 28, 2022 10:26 pm
SavagePencil wrote
What's your high-level main loop (including VBL) look like? I find that detailing out the control and data flows helps me validate what I'm trying to achieve. Once the main loop is confirmed, then we can double click into a few of the stages of that main loop to go deeper into validating.


For gussying up the race track, we may not have to...
Working backwards:
The VDP draws 64 sprite-textures according the table loaded into VRAM
The Z80A calculates the pixel locations of all 64 sprite-textures that build up the cavern and dome
The Binary Space Partitioning tree (as in Doom and most 90s 3D games) may not be necessary either, nor would Z buffering

However, the race car (camera, player) can be anywhere along the track, so we need an 8-bit value for that x location. Otherwise, billboards, trees, signs, and other items drawn as sprite-textures (all above the horizon line) basically run along a track of their own. Perhaps we don't need to calculate those at all, other than adding the 8-bit x value of the race car to their horizontal positions on the track. That is, we may be able to precalculate these tables and load them directly in from the game ROM.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Mon Mar 28, 2022 10:53 pm
So, in the same way that we can pre-render and digitize images for background tiles, we can precalculate the x and y coordinates on the screen for everything that the race car drives past. The Z80A would then only need to add the car's current location with respect to the right side of the track and simply add that to the x position precalculated in the game ROM.

If the number overflows, we don't have to draw that sprite at all.

Assuming that the total width of the playfield is 40 background tiles wide (320x192), and we only display 32x24 tiles, then we have 56 pixels of imagery that don't have to be displayed, depending on how close the race car is to the right side of the track.

Then we use Hang On style color cycling to fill the road with light gray, dark gray, and a few #211 and #000 pixels to create the feeling of the track moving quickly.
  View user's profile Send private message
  • Joined: 23 Aug 2009
  • Posts: 213
  • Location: Seattle, WA
Reply with quote
Post Posted: Mon Mar 28, 2022 11:29 pm
Pretty sure this is how the NES version of Hard Drivin' worked:

I think you do still need your main loop defined. There's player input, there's buffers to fill in ROM and RAM for the VDP to start pulling, and there are a LOT of timing hazards here.
  View user's profile Send private message
Reply to topic Goto page Previous  1, 2, 3, 4  Next



Back to the top of this page

Back to SMS Power!