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 1, 2, 3, 4  Next
Author Message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
advanced mathematics for 3d polygons on the SMS
Post Posted: Sat Mar 05, 2022 11:21 pm
Primarily, what's needed for textured polygon graphics:
"1. Transfer vertex data from memory to the graphics subsystem.
2. Transform vertex coordinates.
3. Transform vertex normals.
4. Light each vertex.
5. Clip each vertex.
6. Project each vertex.
7. Map vertex coordinates to the screen.
8. Fill the resulting screen-space polygons, interpolating color and
depth."

Then apply textures, highlights, shade, reflections, lighting effects, etc.

Proposed, 16-bit single-precision format (as opposed to IEEE 754):
signed 7-bit number for the exponent + 1 bit for mantissa sign
unsigned 8-bit number for the mantissa
mantissa also implies additional 1, giving us a 10-bit fraction
This results in a 10-bit signed fraction, using the Z80A's own logic to handle both signs and exponents. (nVidia can use its own 16-bit floats, which are 10-bit mantissa (11-bit fraction) and 6-bit exponent.)

Multiplication: an 8x8 LookUp Table (LUT) in game ROM (65,536 8-bit results for upper and another 65,536 locations for lower byte result)
Division: Reciprocal approximation and iterative improvement using a 16-bit LUT, including both mantissa and exponent
Reciprocal Square Root: RecipSR approximation and iterative improvement using a 16-bit LUT
(approximately 200KB of game ROM used out of a maximum of 1,024KB)
trigonometric operations also require a one entry, 16-bit LUT with 16-bit results, each requiring 128KB of ROM space

The ALU of the Z80A already has the hardware for the comparisons, adds, and subtraction needed for fast operations on the 8-bit exponent, as well as flags that can be set for overflows if the 2**63 range is exceeded during an operation.

For the full 3D graphics pipeline, it takes approximately 460 floating point operations per polygon, normally making the SMS a poor target for this kind of work. However, if we limited ourselves to transforming vertexes and assume ubiquitous lighting, we can reduce this to 96 floating point (12 mult + 12 adds * four vertexes) operations per rectangle. For contiguous objects, the results of calculations can be stored in RAM and simply reused.

For applying textures, a couple of different techniques can be used:
-using the vertices to calculate the x- and y-coordinates of texture sprites using the Painter's Algorithm--going from furthest away to nearest;
-sprites tiles could be generated each frame by pulling them from the game ROM and drawing them line by line;
-solid colors could be used (like Virtua Racing, Virtua Fighter, etc);
-generic background tiles could be used with color cycling as a way to move highlight and shadow pixels with the moving vertices;
-a small number of sprites per polygon used for small details to give the appearance of full textures

SEGA's custom SVP runs at 23 MHz and can calculate 300 to 500 polygons/frame at 15 frames per second (up to 6,500 polygons per second) with a maximum of 16 colors. That was minimal for the Virtua games, but I wonder if the SMS could manage this level of performance using LUTs and economizations like those mentioned here. 6500 polygons/sec is about 3 Mflops, but I feel like one-tenth that might be achieved on the SMS. Think what we could do with 50 polygons/frame on top of a dithered background.
  View user's profile Send private message
  • Joined: 25 Feb 2006
  • Posts: 863
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Sun Mar 06, 2022 12:38 am
In theory, it should be possible to make 3D polygonal games on the SMS, but it would require some heavy levels of trickery, and the result would require some compromises in terms of graphics quality.

Realistically, it would be possible to make something similar to Elite:


Or Total Eclipse:


Or Sentinel:


Basically, that's somewhat close to what can be achieved on the SMS.
You will probably need to use fixed point instead of floating point, since, while it is less precise, it's orders of magnitude faster, specially on a Z80.
Many of the calculations will have to be replaced with lookup tables.
Many times, it will be necessary to "cheat" a little: "Elite" uses some tricks to approximate rotations by addition, only performing actual multiplications when the error gets too big. "Sentinel" computes an entire 360 degrees panorama only when the player teleports to a new position on the map.

BTW, you might want to take a look at a very early experiment by me:
https://www.smspower.org/forums/9313-PseudoAPARoutinesForTheSegaMasterSystem#425...
  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: Sun Mar 06, 2022 1:15 am
The method that I described for floating point numbers would run faster than fixed point. The reason being that the LUT would only need to be 8x8, not 16x16 (8GB) or 32x32 (which would have to be done in software). IIRC, the PSOne uses a geometry engine with a simple 32x32 integer MAcc pipe, rendering about 180,000 polygons/second.

Using the proposed 16-bit floating point standard (I'm just going to call it Max Floating Point Standard for now) is done to allow 8x8 LUTs of 128KB, something that would fit on a game ROM. The remaining reciprocal, trigonometric operations, reciprocal square root, etc, would then return complete, 16-bit MFPS numbers from a 128KB section or, with the exponents handled in software, 64KB sections.

This would make floating point mathematics happen quickly enough to perform geometry transforms only at the rate of a few hundred polygons/second, faster than I've seen on any Z80 machine, regardless of how much RAM was available.

The VDP then has several techniques available for polygon fills, color cycling for different shading/highlights, etc.
Virtua Racing SVP screenshot.jpet.jpg (664.84 KB)
Virtua Racing on the SVP Megadrive
Virtua Racing SVP screenshot.jpet.jpg

  View user's profile Send private message
  • Joined: 25 Feb 2006
  • Posts: 863
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Sun Mar 06, 2022 9:30 am
maxxoccupancy wrote
The method that I described for floating point numbers would run faster than fixed point. The reason being that the LUT would only need to be 8x8, not 16x16 (8GB) or 32x32 (which would have to be done in software). IIRC, the PSOne uses a geometry engine with a simple 32x32 integer MAcc pipe, rendering about 180,000 polygons/second.

Using the proposed 16-bit floating point standard (I'm just going to call it Max Floating Point Standard for now) is done to allow 8x8 LUTs of 128KB, something that would fit on a game ROM. The remaining reciprocal, trigonometric operations, reciprocal square root, etc, would then return complete, 16-bit MFPS numbers from a 128KB section or, with the exponents handled in software, 64KB sections.

This would make floating point mathematics happen quickly enough to perform geometry transforms only at the rate of a few hundred polygons/second, faster than I've seen on any Z80 machine, regardless of how much RAM was available.

The VDP then has several techniques available for polygon fills, color cycling for different shading/highlights, etc.


How do you propose to make the floating point addition/subtraction work at speeds that are competitive with fixed point?
  View user's profile Send private message Visit poster's website
  • Joined: 25 Feb 2006
  • Posts: 863
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Sun Mar 06, 2022 3:00 pm
An interesting video on the optimizations used by Elite:
  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: Sun Mar 06, 2022 4:54 pm
haroldoop wrote
maxxoccupancy wrote
The method that I described for floating point numbers would run faster than fixed point. The reason being that the LUT would only need to be 8x8, not 16x16 (8GB) or 32x32 (which would have to be done in software). IIRC, the PSOne uses a geometry engine with a simple 32x32 integer MAcc pipe, rendering about 180,000 polygons/second.

Using the proposed 16-bit floating point standard (I'm just going to call it Max Floating Point Standard for now) is done to allow 8x8 LUTs of 128KB, something that would fit on a game ROM. The remaining reciprocal, trigonometric operations, reciprocal square root, etc, would then return complete, 16-bit MFPS numbers from a 128KB section or, with the exponents handled in software, 64KB sections.

This would make floating point mathematics happen quickly enough to perform geometry transforms only at the rate of a few hundred polygons/second, faster than I've seen on any Z80 machine, regardless of how much RAM was available.

The VDP then has several techniques available for polygon fills, color cycling for different shading/highlights, etc.


How do you propose to make the floating point addition/subtraction work at speeds that are competitive with fixed point?


There's no way to get 16-bit floating point (8-bit exponent and 8-bit mantissa) to add and subtract faster than 16-bit fixed point in the ALU. However, the total number of instructions to perform a simple fp multiply, division, square root, etc, vs. doing the same in fixed point through software is where we see the difference. Much of the time spent on 3D graphics polygon math is spent on these more difficult operations.

Using an exponent allows us to get away with a 10-bit fraction:
+/- 1.xxx * 10**19

So long as we normalize twice for subtraction, we follow the law that, where x > 2y > 2x (x and y are close), x - y will always be computed exactly. With fixed point numbers, 16 bits are sometimes not enough because of the occasional computation where several bits of accuracy are lost in one operation where the programmer has no way of ever finding out that it's been lost.

That is why the PlayStation 1 used 32-bit fixed point, still getting botchy, wobbly results. Its integer hardware wasn't up to the task, and its floating point hardware was non-existent.

So a better comparison would be between 16-bit MFPS numbers and 32-bit fixed point.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
16-bit floating point vs. 16-bit fixed point
Post Posted: Sun Mar 06, 2022 8:30 pm
Actually, IIRC, William Kahan was trying to get the IEEE 754 floating point format to roughly resemble 32- and 64-bit integers for comparisons. Since we only need about five bits of exponent, I wonder if there's a way to build a quick and dirty format where we read the same number as a 8+8 floating point number for multiply, divide, etc, but still add the numbers together as though they were integers.

Any carry from the lower 8-bit mantissa would automatically increment the exponent, just as it does in floating point hardware, so floating point adds would be handles as a 16-bit add. Floating point subtraction would have to check for zeros at the MSB of the mantissa. If 0, it would have to perform the operation again to recover the guard and round bits, but would still be relatively fast.

That would allow rough but very fast fp on the Z80. The numbers would not be linear like fixed point, but would still cover sufficient range for vertexes.

Another approach for fast multiplies by matrices is to read in the matrix values and use a macro to write up a series of shift-adds--a subroutine to multiply any array of numbers by a fixed transform matrix. That is possible because the Z80 lacks an instruction cache and can modify its own code.

I would still use LUTs for the more complex fp operations, though.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Mon Mar 14, 2022 4:42 am
Here's an example of the Game Boy Advance, with a CPU and hardware similar to that of the Megadrive, putting PlayStation level 3D graphics onscreen.

It turns out that they're using many of the LookUp Tables and optimizations that I've mentioned in this thread. The SMS is absolutely capable of 3D graphics, decent polygon counts, and even rendering images at usable frame rates.



This is all done at 240x160 and 256 colors--not far off from the 256x192 and 32 out of 64 colors on the SMS.

As I'd suggested, there is no need for a Z buffer if the Painter's Algorithm is used--similar to the Atari Lynx.

And here's "realtime raytracing" on the SNES.


Now that SMS game cartridges can hold 4MB (including multiple 64KB and 128KB LookUp Tables), we may be able to get two orders of magnitude improvement in 3D graphics--perhaps as high as the SFX or SVP chips.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Mon Mar 14, 2022 5:18 am
The current thinking on 3D graphics is that the smallest primitive possible is a three pointed polygon (triangle in the 3D space) with three vertexes, each of which has four floating point numbers that represent it. This is how we end up with 46 floating point operations per vertex or 138 flop's per polygon.

However, we are trying to get to a normal, or direction that the triangle is facing. If we limit the size of every polygon--to a size less than a sprite, for example--then all we need is one vertex or point in 3D space and a normal or direction that the surface is pointing at.

If we were just drawing pixels alone, we could simply use raycasting--one ray per pixel out of 49,152 pixels--find the face and normal at that point, find the color of that face, then shade it based on the angle from the primary light source, and generate a pixel.

I'll have to think about this, but it may be possible to have the Z80A generate tables that use the background color palette to look up the numbers on each tile to figure out R, G, and B values there.

Perhaps the 4-bit number at a location in VRAM could tell us the color of the face at that point, and subsequent lookup could be used to provide the highlight or shadow at that point. There are a couple of extra bits free in the CRAM that could make this all work.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14685
  • Location: London
Reply with quote
Post Posted: Mon Mar 14, 2022 7:08 am
I think there’s a few gaps in what you suggest (highlight and shadow? Readable CRAM?) so really a proof of concept is needed. Draw one unshaded moving triangle on SMS and see what frame rate you can do.
  View user's profile Send private message Visit poster's website
  • Joined: 25 Feb 2006
  • Posts: 863
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Mon Mar 14, 2022 9:32 am
The GBA uses a 32bit ARM CPU with a RISC architecture, while the Sega Genesis uses a 16bit M68K CPU, with a CISC architecture, they are completely different beasts.

Plus, some of the GBA video modes include a linear framebuffer, something that neither SMS, nor SMD offer.

As for the SNES raytracing demo, it uses a modern FPGA inside the cartridge doing the vast majority of the processing.

If you want to use modern CPUs to boost the processing power, you could probably do something like Wolf 3D:

Basically, this one uses an ARM-based microcontroller on the cartridge to run the entire game logic, while the GBC only copies the finished tile data from the cartridge to the VRAM.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Mar 14, 2022 10:38 am
addressing single pixels is surely possible, but it's very very slow.
sure you could code a 3D renderer, I just think it won't ever be fast enough
or you could render at 32×24 using whole tiles as pixels... very chunky but probably possible
  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 844
Reply with quote
Post Posted: Mon Mar 14, 2022 10:41 am
maxxoccupancy wrote
The SMS is absolutely capable of 3D graphics, decent polygon counts, and even rendering images at usable frame rates.


Unless I'm overlooking something, the SMS absolutely isn't.

Keep in mind that the SMS does not have any kind of bitmap graphics mode. Thus, you can't just draw dots and lines on the screen anywhere you want. You always have to slice your image into 8x8 pixel tiles, then transfer the tiles to the video memory and update the name table accordingly. Transfering tile data and updating the name table can take a lot of time, as it all has to happen through the bottleneck that is the VDP control port. There's no DMA on the SMS. Think of it like trying to restock shelves in a storage room, but having to push each can through the key hole. I very much doubt you can get a stable, fast enough screen refresh rate, even if you somehow miraculously manage to make the calculations really fast.

You could use the SG-1000 legacy graphics mode, which iirc can work in some kind of bitmap mode to draw your screen, but of course then you're stuck with much fewer (fixed) colours. F-16 Fighter / Fighting Falcon does this, and I think the game, choppy as it is, actually shows the pinnacle of what's possible in terms of 3D on the SMS.

I'd love you to prove me wrong, though.
  View user's profile Send private message
  • Joined: 25 Feb 2006
  • Posts: 863
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Mon Mar 14, 2022 11:50 am
In fact, if you want to make a proof of concept, you could start by drawing a single, flat colored, 2D triangle on screen, and then modify the routine to keep drawing other random triangles on top of the existing ones. If you cannot make the 2D flat-shaded triangle draw fast, it won't be possible to render them fast in 3D.
  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: Mon Mar 14, 2022 2:29 pm
haroldoop wrote
In fact, if you want to make a proof of concept, you could start by drawing a single, flat colored, 2D triangle on screen, and then modify the routine to keep drawing other random triangles on top of the existing ones. If you cannot make the 2D flat-shaded triangle draw fast, it won't be possible to render them fast in 3D.


I'm saying:
Don't draw polygons. Instead, draw the face as something that is limited in radius to just a few pixels--or even one. Then calculate the normal of that. The SMS wasn't designed for handling 180,000 polygons/sec like the 32X.

Any algorithm for the SMS should take into account the limited hardware that is there. The VDP reads tiles of numbers--not colors. It then performs a lookup process from those numbers and displays the chosen color (from among two sets of 16 out of 64 total) to the screen.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Mon Mar 14, 2022 2:39 pm
Kagesan wrote
maxxoccupancy wrote
The SMS is absolutely capable of 3D graphics, decent polygon counts, and even rendering images at usable frame rates.


Unless I'm overlooking something, the SMS absolutely isn't.

Keep in mind that the SMS does not have any kind of bitmap graphics mode. Thus, you can't just draw dots and lines on the screen anywhere you want. You always have to slice your image into 8x8 pixel tiles, then transfer the tiles to the video memory and update the name table accordingly. Transfering tile data and updating the name table can take a lot of time, as it all has to happen through the bottleneck that is the VDP control port. There's no DMA on the SMS. Think of it like trying to restock shelves in a storage room, but having to push each can through the key hole. I very much doubt you can get a stable, fast enough screen refresh rate, even if you somehow miraculously manage to make the calculations really fast.

You could use the SG-1000 legacy graphics mode, which iirc can work in some kind of bitmap mode to draw your screen, but of course then you're stuck with much fewer (fixed) colours. F-16 Fighter / Fighting Falcon does this, and I think the game, choppy as it is, actually shows the pinnacle of what's possible in terms of 3D on the SMS.

I'd love you to prove me wrong, though.


Again, look at the hardware that's actually there. The game itself decides which tiles go into VRAM (someone state the bandwidth if you know it), then where they get placed, and the VDP draws those from the many 4-bit numbers in there.

Some of the techniques that I described at the top of this thread later turned out to already be in use in Tomb Raider and other 3D games running on hardware that had no 3D rendering pipeline to speak of.

Are you saying that a 64 sprite/polygon version of Virtua Fighter can't be made with 32 sprite/polygons per player? Placing 64 sprites per frame is what the Z80A does with every other game.
  View user's profile Send private message
  • Joined: 25 Feb 2006
  • Posts: 863
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Mon Mar 14, 2022 2:45 pm
maxxoccupancy wrote
Kagesan wrote
maxxoccupancy wrote
The SMS is absolutely capable of 3D graphics, decent polygon counts, and even rendering images at usable frame rates.


Unless I'm overlooking something, the SMS absolutely isn't.

Keep in mind that the SMS does not have any kind of bitmap graphics mode. Thus, you can't just draw dots and lines on the screen anywhere you want. You always have to slice your image into 8x8 pixel tiles, then transfer the tiles to the video memory and update the name table accordingly. Transfering tile data and updating the name table can take a lot of time, as it all has to happen through the bottleneck that is the VDP control port. There's no DMA on the SMS. Think of it like trying to restock shelves in a storage room, but having to push each can through the key hole. I very much doubt you can get a stable, fast enough screen refresh rate, even if you somehow miraculously manage to make the calculations really fast.

You could use the SG-1000 legacy graphics mode, which iirc can work in some kind of bitmap mode to draw your screen, but of course then you're stuck with much fewer (fixed) colours. F-16 Fighter / Fighting Falcon does this, and I think the game, choppy as it is, actually shows the pinnacle of what's possible in terms of 3D on the SMS.

I'd love you to prove me wrong, though.


Again, look at the hardware that's actually there. The game itself decides which tiles go into VRAM (someone state the bandwidth if you know it), then where they get placed, and the VDP draws those from the many 4-bit numbers in there.

Some of the techniques that I described at the top of this thread later turned out to already be in use in Tomb Raider and other 3D games running on hardware that had no 3D rendering pipeline to speak of.

Are you saying that a 64 sprite/polygon version of Virtua Fighter can't be made with 32 sprite/polygons per player? Placing 64 sprites per frame is what the Z80A does with every other game.


If you use sprites for the role of tiny polygons, most of the time, you will need to place them on top of each other, which will reach the 8 sprites per line even earlier than you normally would.
  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: Mon Mar 14, 2022 2:47 pm
haroldoop wrote
The GBA uses a 32bit ARM CPU with a RISC architecture, while the Sega Genesis uses a 16bit M68K CPU, with a CISC architecture, they are completely different beasts.

Plus, some of the GBA video modes include a linear framebuffer, something that neither SMS, nor SMD offer.

As for the SNES raytracing demo, it uses a modern FPGA inside the cartridge doing the vast majority of the processing.

If you want to use modern CPUs to boost the processing power, you could probably do something like Wolf 3D:

Basically, this one uses an ARM-based microcontroller on the cartridge to run the entire game logic, while the GBC only copies the finished tile data from the cartridge to the VRAM.


The Sega Master System actually does have a 14MHz 16-bit RISC processor onboard. It's the VDP. And it does have a powerful geometry engine that we haven't been using. It's a series of 64KB and 128KB LookUp Tables on the ROM cart. The hardware wasn't designed for rendering 3D graphics, you say? Outrun, Hang On, Space Harrier, Zaxxon, Missile Defense, and many other 3D games forced SEGA's engineers to come up with hardware to do this.

Texturing and Garaud shading are impossible, you say? Background tiles can hold a swatch of 16 colors. With color cycling, that can be four banks of four colors. So a wall in Wolfenstein or a dungeon crawler could have four colors that are color cycled past you just like those waterfalls and lava flows in the background, but coming back toward you.

There is more than one way to skin a cat.
  View user's profile Send private message
  • Joined: 05 Jun 2010
  • Posts: 757
  • Location: Pennsylvania, USA
Reply with quote
Post Posted: Mon Mar 14, 2022 3:25 pm
Well, as maxim said, make a demo/proof of concept and see where you get. Maybe you're right, but we'll never know until someone tries it.
  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 844
Reply with quote
Post Posted: Mon Mar 14, 2022 5:22 pm
maxxoccupancy wrote
Again, look at the hardware that's actually there. The game itself decides which tiles go into VRAM (someone state the bandwidth if you know it), then where they get placed, and the VDP draws those from the many 4-bit numbers in there.


Sorry if the following sounds rude, it's not really meant that way. I'm quite familiar with the hardware that's there, I'm not sure you are, though.

The above paragraph makes no sense to me. You describe exactly the bottleneck I talked about earlier, but somehow it isn't a problem, because… "the game itself decides which tiles go into VRAM"? Care to elaborate? I think it's quite likely I misunderstand you, but I can't make heads or tails of what you're trying to say here.


maxxoccupancy wrote
Outrun, Hang On, Space Harrier, Zaxxon, Missile Defense, and many other 3D games forced SEGA's engineers to come up with hardware to do this.


These are all essentially 2D games that just create the illusion of movement along the z-axis through graphical trickery. Their gameplay doesn't take place in an actual three-dimensional space.
  View user's profile Send private message
  • Joined: 23 Jan 2010
  • Posts: 413
Reply with quote
Post Posted: Mon Mar 14, 2022 6:21 pm
maxxoccupancy wrote
haroldoop wrote
In fact, if you want to make a proof of concept, you could start by drawing a single, flat colored, 2D triangle on screen, and then modify the routine to keep drawing other random triangles on top of the existing ones. If you cannot make the 2D flat-shaded triangle draw fast, it won't be possible to render them fast in 3D.


I'm saying:
Don't draw polygons. Instead, draw the face as something that is limited in radius to just a few pixels--or even one. Then calculate the normal of that. The SMS wasn't designed for handling 180,000 polygons/sec like the 32X.

Any algorithm for the SMS should take into account the limited hardware that is there. The VDP reads tiles of numbers--not colors. It then performs a lookup process from those numbers and displays the chosen color (from among two sets of 16 out of 64 total) to the screen.

You are expert in a especific platform ? Genesis/MD for example?
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Mon Mar 14, 2022 11:31 pm
Kagesan wrote
maxxoccupancy wrote
Again, look at the hardware that's actually there. The game itself decides which tiles go into VRAM (someone state the bandwidth if you know it), then where they get placed, and the VDP draws those from the many 4-bit numbers in there.


Sorry if the following sounds rude, it's not really meant that way. I'm quite familiar with the hardware that's there, I'm not sure you are, though.

The above paragraph makes no sense to me. You describe exactly the bottleneck I talked about earlier, but somehow it isn't a problem, because… "the game itself decides which tiles go into VRAM"? Care to elaborate? I think it's quite likely I misunderstand you, but I can't make heads or tails of what you're trying to say here.


maxxoccupancy wrote
Outrun, Hang On, Space Harrier, Zaxxon, Missile Defense, and many other 3D games forced SEGA's engineers to come up with hardware to do this.


These are all essentially 2D games that just create the illusion of movement along the z-axis through graphical trickery. Their gameplay doesn't take place in an actual three-dimensional space.


I just looked at the OP and realized that I've thrown some people off. I was quoting the traditional 3D rendering pipeline that is done in hardware from the PlayStation/Saturn onward. The SMS/MD Gameboy Advance, etc, don't have that pipeline. However, the MD and GBA have been using their integer/sprite hardware and CPU to produce beautiful, stunning 3D graphics.

To be fair, the PlayStation and Saturn don't actually create holographic 3D environments, but simply stretch textures, draw them to the screen performing some clever after effects. With 4 micron litho and only a few thousand transistors per chip, they had to use much simpler methods of synthesizing 3D worlds, but the end goal is the same.

What I'm suggesting for Virtua games is to load 448 tiles of solid colors in different shapes, then having precomputed tables in the game ROM, then simply having the Z80A update the tables in VRAM using the Painter's Algorithm.

That is to say, that background tiles could be used to generate non-moving 3D backgrounds like the track from Virtua Racing. Sprite tiles would be needed to draw 3D moving characters with polygon/sprites drawing over polygon/sprites until you get 32-sprite characters on each side of the screen.

If I had a 3D SMS racing game like Hang On or Outrun to work with, I could show you what I mean. For a Virtua Fighter style game, we could take an existing 2D game and replace all of the assets with pre-rendered 3D objects, putting it all together in a 3D environment.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Mon Mar 14, 2022 11:36 pm
Kagesan wrote
maxxoccupancy wrote
Again, look at the hardware that's actually there. The game itself decides which tiles go into VRAM (someone state the bandwidth if you know it), then where they get placed, and the VDP draws those from the many 4-bit numbers in there.


Sorry if the following sounds rude, it's not really meant that way. I'm quite familiar with the hardware that's there, I'm not sure you are, though.

The above paragraph makes no sense to me. You describe exactly the bottleneck I talked about earlier, but somehow it isn't a problem, because… "the game itself decides which tiles go into VRAM"? Care to elaborate? I think it's quite likely I misunderstand you, but I can't make heads or tails of what you're trying to say here.


maxxoccupancy wrote
Outrun, Hang On, Space Harrier, Zaxxon, Missile Defense, and many other 3D games forced SEGA's engineers to come up with hardware to do this.


These are all essentially 2D games that just create the illusion of movement along the z-axis through graphical trickery. Their gameplay doesn't take place in an actual three-dimensional space.


That is what every 3D video game since Battlezone has tried to do. Heck, even 3D Monster Maze in 1981 and Pole Position used electronic magic tricks to give the illusion of an immersive 3D environment.

What I'm saying is that there is still quite a bit of umph left in the old SMS that is not being put to use. There are quite a few hacks left that could help up the frame rate and improve smoothness, filling out an environment with scaling objects.
  View user's profile Send private message
  • Joined: 23 Aug 2009
  • Posts: 213
  • Location: Seattle, WA
Reply with quote
Post Posted: Tue Mar 15, 2022 7:37 pm
start writing some code, dude
  View user's profile Send private message
  • Joined: 04 Oct 2019
  • Posts: 74
  • Location: Brazil
Reply with quote
Post Posted: Tue Mar 15, 2022 8:18 pm
This is just partially offtopic, but kinda fits in the subject. You know what I miss? New games for the Sega 3D glasses. That is some actually nice 3D and obviously feasible. ^^
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Wed Mar 16, 2022 3:04 am
SavagePencil wrote
start writing some code, dude


I still need more feedback from folks who understand the ins and outs of the SMS1 & 2 hardware. After weeks of searching, someone finally pointed out (after some mathematics) that the game ROM to VRAM bandwidth is 170KB/sec, or enough to change at most 20% of the screen each frame.

Next is seeing what the performance limits are using SDCC and the devkitSMS. It would be better if I could work with someone who had already made racing games like Hang On, Outrun, or Road Rash for the SMS.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Mar 16, 2022 9:10 am
maxxoccupancy wrote
The Sega Master System actually does have a 14MHz 16-bit RISC processor onboard. It's the VDP.


I don't agree with this. I wouldn't call it 'a processor' since you can't feed it a program. Sure it's a graphic chip, sure you can manipulate it in some creative ways, but that's what you get.

maxxoccupancy wrote
Next is seeing what the performance limits are using SDCC and the devkitSMS.


For such advanced topics I wouldn't even mention writing high level code. Your enthusiasm is appreciated, and I'm sure you'll learn Z80 asm quickly and see the world for yourself.
  View user's profile Send private message Visit poster's website
  • Joined: 25 Feb 2006
  • Posts: 863
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Wed Mar 16, 2022 9:14 am
maxxoccupancy wrote
SavagePencil wrote
start writing some code, dude


I still need more feedback from folks who understand the ins and outs of the SMS1 & 2 hardware. After weeks of searching, someone finally pointed out (after some mathematics) that the game ROM to VRAM bandwidth is 170KB/sec, or enough to change at most 20% of the screen each frame.

Next is seeing what the performance limits are using SDCC and the devkitSMS. It would be better if I could work with someone who had already made racing games like Hang On, Outrun, or Road Rash for the SMS.


AFAIK, all of those use prescaled sprites.
  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 19, 2022 8:13 pm
sverx wrote
maxxoccupancy wrote
The Sega Master System actually does have a 14MHz 16-bit RISC processor onboard. It's the VDP.


I don't agree with this. I wouldn't call it 'a processor' since you can't feed it a program. Sure it's a graphic chip, sure you can manipulate it in some creative ways, but that's what you get.

maxxoccupancy wrote
Next is seeing what the performance limits are using SDCC and the devkitSMS.


For such advanced topics I wouldn't even mention writing high level code. Your enthusiasm is appreciated, and I'm sure you'll learn Z80 asm quickly and see the world for yourself.


It's not Turing Complete, as it doesn't do branching per se. Yet it definitely functions just like the texture drawing coprocessors on the end of the graphics pipeline. That hints that the Z80A would only need to perform the object physics and GTE work--but producing tables for the background tiles and sprite-textures.

Using LUT's on the game ROM to calculate the locations of vertexes and perform clipping operations, I don't see that the SMS couldn't render 3D graphics on the fly.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Mar 21, 2022 9:25 am
if you give it enough time it can render whatever you want... but again even LUT access isn't free (it still takes some time) and you don't exactly have a framebuffer, not to mention again the fact that VRAM is planar and accessed through the VDP only.
You can probably spin a small wireframe cube at a 'not so terrible' speed, though.
  View user's profile Send private message Visit poster's website
  • Joined: 09 Aug 2021
  • Posts: 106
Reply with quote
Post Posted: Mon Mar 21, 2022 3:27 pm
maxxoccupancy wrote
Using LUT's on the game ROM to calculate the locations of vertexes and perform clipping operations, I don't see that the SMS couldn't render 3D graphics on the fly.

why you are not trying to make a proof-of-concept project?
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Mon Mar 21, 2022 4:34 pm
toxa wrote
maxxoccupancy wrote
Using LUT's on the game ROM to calculate the locations of vertexes and perform clipping operations, I don't see that the SMS couldn't render 3D graphics on the fly.

why you are not trying to make a proof-of-concept project?


I am. I keep asking for a game template like Road Rash or Hang On. No one has been able to point me to one.
  View user's profile Send private message
  • Joined: 25 Feb 2006
  • Posts: 863
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Mon Mar 21, 2022 4:41 pm
maxxoccupancy wrote
toxa wrote
maxxoccupancy wrote
Using LUT's on the game ROM to calculate the locations of vertexes and perform clipping operations, I don't see that the SMS couldn't render 3D graphics on the fly.

why you are not trying to make a proof-of-concept project?


I am. I keep asking for a game template like Road Rash or Hang On. No one has been able to point me to one.


Because nobody tried to make this kind of homebrew on the SMS. Also, both games use prescaled sprites, plus raster splits. It's a completely different tech compared to polygons.
  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: Mon Mar 21, 2022 4:54 pm
haroldoop wrote
maxxoccupancy wrote
toxa wrote
maxxoccupancy wrote
Using LUT's on the game ROM to calculate the locations of vertexes and perform clipping operations, I don't see that the SMS couldn't render 3D graphics on the fly.

why you are not trying to make a proof-of-concept project?


I am. I keep asking for a game template like Road Rash or Hang On. No one has been able to point me to one.


Because nobody tried to make this kind of homebrew on the SMS. Also, both games use prescaled sprites, plus raster splits. It's a completely different tech compared to polygons.


Alternately, I could use a parallax side scroller to make the point. 3D graphics are built up out of 3D effects. Modern consoles only use textured polygons, which is very floating point intensive. However, the SMS more closely resembles the many super scaling arcade machines of its generation (1985-92). I'm not the only one who's suggested using sprites to paint textures, but I'd have to have some kind of game template to start with, and everything in the Homebrew section is overhead or platformer. Adding 3D effects to those is difficult.
  View user's profile Send private message
  • Joined: 23 Jan 2010
  • Posts: 413
Reply with quote
Post Posted: Mon Mar 21, 2022 6:26 pm
Last edited by segarule on Tue Mar 22, 2022 12:14 pm; edited 2 times in total
Maybe you want something like as this:

BUT it is a MSX 2 demo. MSX 2 have more memory and more video memory, besides the VDP have more resolution, more modes and vertical scrolling registers.
Dont take me wrong but you speaked with most of best devs here in forum. I kindly suggest you to take all advices given from them. What about take an other way and make something feasible? Why not do a conversion to SMS? The fans claimed a King´s valley 2 to SMS. Or you can make a hack or a Homebrew. Im sure that members here will be happy much more than an unlikely tech demo. But if you believe that you can do it...go ahead.
  View user's profile Send private message
  • Joined: 25 Feb 2006
  • Posts: 863
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Mon Mar 21, 2022 8:15 pm
maxxoccupancy wrote
haroldoop wrote
maxxoccupancy wrote
toxa wrote
maxxoccupancy wrote
Using LUT's on the game ROM to calculate the locations of vertexes and perform clipping operations, I don't see that the SMS couldn't render 3D graphics on the fly.

why you are not trying to make a proof-of-concept project?


I am. I keep asking for a game template like Road Rash or Hang On. No one has been able to point me to one.


Because nobody tried to make this kind of homebrew on the SMS. Also, both games use prescaled sprites, plus raster splits. It's a completely different tech compared to polygons.


Alternately, I could use a parallax side scroller to make the point. 3D graphics are built up out of 3D effects. Modern consoles only use textured polygons, which is very floating point intensive. However, the SMS more closely resembles the many super scaling arcade machines of its generation (1985-92). I'm not the only one who's suggested using sprites to paint textures, but I'd have to have some kind of game template to start with, and everything in the Homebrew section is overhead or platformer. Adding 3D effects to those is difficult.



As I mentioned before, there are a few pieces of source code / documentation that you could study, in order to understand how to make a pseudo-3d road:
- Lou's Pseudo 3d Page explains how those routines tend to be implemented: http://www.extentofthejam.com/pseudo/
- This shows how to use SMS's raster interrupt feature to use different scrolling per line: https://www.smspower.org/Homebrew/RasterParallax-SMS
- This Sega Genesis homebrew shows how to use the trick on SGDK: https://github.com/radioation/MegaDriving

So, basically, based on the above, you will need to:
- Understand the theory behind the pseudo 3D effects used in 8-bit racing games;
- Understand how Sega Mega Drive's raster interrupt can be used to implement line scrolling, which can be used, among other things, for a pseudo-3D trick that can be used on the Sega Mega Drive;
- Understand how to use Sega Master System's raster interrupt feature to implement line scrolling on the Sega Master System;
- Use Sega Master System's line scrolling capabilities to replicate the same trick used on Sega Mega Drive, but keeping in mind that the SMS does not support vertical line scrolling, only horizontal.
  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: Mon Mar 21, 2022 10:13 pm
haroldoop wrote
maxxoccupancy wrote
haroldoop wrote
maxxoccupancy wrote
toxa wrote
maxxoccupancy wrote
Using LUT's on the game ROM to calculate the locations of vertexes and perform clipping operations, I don't see that the SMS couldn't render 3D graphics on the fly.

why you are not trying to make a proof-of-concept project?


I am. I keep asking for a game template like Road Rash or Hang On. No one has been able to point me to one.


Because nobody tried to make this kind of homebrew on the SMS. Also, both games use prescaled sprites, plus raster splits. It's a completely different tech compared to polygons.


Alternately, I could use a parallax side scroller to make the point. 3D graphics are built up out of 3D effects. Modern consoles only use textured polygons, which is very floating point intensive. However, the SMS more closely resembles the many super scaling arcade machines of its generation (1985-92). I'm not the only one who's suggested using sprites to paint textures, but I'd have to have some kind of game template to start with, and everything in the Homebrew section is overhead or platformer. Adding 3D effects to those is difficult.



As I mentioned before, there are a few pieces of source code / documentation that you could study, in order to understand how to make a pseudo-3d road:
- Lou's Pseudo 3d Page explains how those routines tend to be implemented: http://www.extentofthejam.com/pseudo/
- This shows how to use SMS's raster interrupt feature to use different scrolling per line: https://www.smspower.org/Homebrew/RasterParallax-SMS
- This Sega Genesis homebrew shows how to use the trick on SGDK: https://github.com/radioation/MegaDriving

So, basically, based on the above, you will need to:
- Understand the theory behind the pseudo 3D effects used in 8-bit racing games;
- Understand how Sega Mega Drive's raster interrupt can be used to implement line scrolling, which can be used, among other things, for a pseudo-3D trick that can be used on the Sega Mega Drive;
- Understand how to use Sega Master System's raster interrupt feature to implement line scrolling on the Sega Master System;
- Use Sega Master System's line scrolling capabilities to replicate the same trick used on Sega Mega Drive, but keeping in mind that the SMS does not support vertical line scrolling, only horizontal.


That's fair enough. But I'm saying that, if someone else already has a sidescrolling shoot em up with code (or a Hang On, Space Harrier game), then I can add some of the 3D effects that I'm talking about. I've seen each of these elements elsewhere--some of them smoothly implemented on the SMS--but never all at once in the same game.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Tue Mar 22, 2022 5:51 am
For every ten people who insist that it can't be done, there is someone out there who has already done it. This animation looks quite smooth when they're moved at 30-60fps.

And it looks quite 3D.

For a Formula 1 car, use animated sprites for the wheels and four more pre-rendered or digitized sprites for the rest.

  View user's profile Send private message
  • Joined: 25 Feb 2006
  • Posts: 863
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Tue Mar 22, 2022 10:02 am
maxxoccupancy wrote
For every ten people who insist that it can't be done, there is someone out there who has already done it. This animation looks quite smooth when they're moved at 30-60fps.

And it looks quite 3D.

For a Formula 1 car, use animated sprites for the wheels and four more pre-rendered or digitized sprites for the rest.


That would be a good idea on a hardware with more robust sprite capabilities, but not on the SMS.
  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 844
Reply with quote
Post Posted: Tue Mar 22, 2022 10:50 am
It's still very confusing what you're aiming at. On one hand you're talking about polygons and 3D maths, which imply "real" 3D graphics that the SMS is ill-equipped to produce, then suddenly you're talking about pseudo-3D games, sprites, and parallax scrolling. Those are fundamentally different things that aren't the least bit alike.

You also ignore everything that seasoned developers keep telling you about VDP bandwidth, sprite limitations and screen modes. Instead you insist that "it can be done, because it has been done on [insert hardware that's completely different from the SMS]".

My suggestion: 1. Define exactly which effect you want to achieve. 2. Code a proof of concept demo of it.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 129
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Tue Mar 22, 2022 5:57 pm
Kagesan wrote
It's still very confusing what you're aiming at. On one hand you're talking about polygons and 3D maths, which imply "real" 3D graphics that the SMS is ill-equipped to produce, then suddenly you're talking about pseudo-3D games, sprites, and parallax scrolling. Those are fundamentally different things that aren't the least bit alike.

You also ignore everything that seasoned developers keep telling you about VDP bandwidth, sprite limitations and screen modes. Instead you insist that "it can be done, because it has been done on [insert hardware that's completely different from the SMS]".

My suggestion: 1. Define exactly which effect you want to achieve. 2. Code a proof of concept demo of it.


Yup. I feel like I'm saying the same thing over and over again:
1. Start with the strengths of the powerful VDP, a 14MHz, 16-bit RISC engine: use it to draw sprite-textures at specific, moving locations, just like the last stage of a conventional 3D graphics pipeline
2. Use the Z-80A (60,000 cycles per frame) to calculate the changing locations of those sprites on the screen
3. Use the new, 32 megabit game cartridges (which were technically possible in the 1990s) to hold large LookUp Tables for the more complex mathematics
4. Use modern workstations and software to replicate the work of those $200,000 Silicon Graphics workstations that only the largest game development companies had for prerendered graphics
5. Use techniques like sprite separation (four sprites gradually moved apart as an object moves "closer" to the camera)
6. Use color cycling on large background tiles to give the visual effect of textures moving past you, similar to Hang On and Super Monaco GP

You build the algorithm around the hardware that you have. Efforts to do the opposite have resulted in slow moving, monochrome wireframes that wouldn't impress anyone.

No one thought that Doom could be ported to the SNES, nor that Tomb Raider could be ported to the GBA. However, they both used some of the same techniques that I've been describing here.
  View user's profile Send private message
  • Joined: 04 Jul 2010
  • Posts: 539
  • Location: Angers, France
Reply with quote
Post Posted: Tue Mar 22, 2022 6:23 pm
Please stop blathering and make a POC.
  View user's profile Send private message
  • Joined: 09 Aug 2021
  • Posts: 106
Reply with quote
Post Posted: Tue Mar 22, 2022 8:02 pm
maxxoccupancy wrote
No one thought that Doom could be ported to the SNES, nor that Tomb Raider could be ported to the GBA. However, they both used some of the same techniques that I've been describing here.

SNES is a 16-bit machine with a clever design. GBA is a 32-bit monster.

techniques, you are describing, do not fit well with SMS.
  View user's profile Send private message
  • Joined: 25 Feb 2006
  • Posts: 863
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Tue Mar 22, 2022 9:22 pm
toxa wrote
maxxoccupancy wrote
No one thought that Doom could be ported to the SNES, nor that Tomb Raider could be ported to the GBA. However, they both used some of the same techniques that I've been describing here.

SNES is a 16-bit machine with a clever design. GBA is a 32-bit monster.

techniques, you are describing, do not fit well with SMS.


Also, Doom for SNES used the SuperFX2 chip on the cartridge. Plain SNES with no enhancements wouldn't be nearly powerful enough to run Doom.

Now, among your list, let's check the viability:

Quote
1. Start with the strengths of the powerful VDP, a 14MHz, 16-bit RISC engine: use it to draw sprite-textures at specific, moving locations, just like the last stage of a conventional 3D graphics pipeline


Nope. It's not as powerful as you describe.

Quote
2. Use the Z-80A (60,000 cycles per frame) to calculate the changing locations of those sprites on the screen


That's doable. But always keep in mind the 8 sprites per line limit. You will hit it pretty quick.

Quote
3. Use the new, 32 megabit game cartridges (which were technically possible in the 1990s) to hold large LookUp Tables for the more complex mathematics


Could be done, but it probably won't be as fast as you expect. Plus, the VDP limitations will be the greatest bottleneck by far. No amount of tables in ROM will prevent that.

Quote
4. Use modern workstations and software to replicate the work of those $200,000 Silicon Graphics workstations that only the largest game development companies had for prerendered graphics


Could be done. Sonic Blast used that, even if it's not a very good example.

You could use this technique to create the prescaled sprites.

Quote
5. Use techniques like sprite separation (four sprites gradually moved apart as an object moves "closer" to the camera)


That can certainly be done on the SMS, but always keep in mind the limit 8 sprites per line.

Quote
6. Use color cycling on large background tiles to give the visual effect of textures moving past you, similar to Hang On and Super Monaco GP


That is also doable on the SMS, as long as the gameplay is somewhat on-rails.

Another alternative would be to create a prerendered video stored on cartridge to serve as the background, similarly to what is Toy Story Racer for the GBC does:

Katakis 3D for the GBC also uses a variation of the trick:


This would require the gameplay to be even more on rails than in the case of the color cycling trick, but it could work within the limits of the SMS.

There are already a few SMS homebrews out there that play video, though they aren't really optimized to do that while also leaving time for doing something else; it probably would be necessary to reduce video quality to use less tiles, in order to leave some free for the prescaled sprites.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14685
  • Location: London
Reply with quote
Post Posted: Tue Mar 22, 2022 9:59 pm
You can do whatever maths you like but your 64 8x8 sprites with at most 8 on any scanline will hardly fill the screen. You can try to stream "textures" onto those sprites from your large ROM within the timing limitations but they'll still fill a tiny part of the screen. Doing raster FX with the rest will hardly make up for it.

In the end, the VDP is not a RISC engine, it's a chip that draws 8x8 squares on a grid plus some extra squares at arbitrary positions. The CPU can try its best to make the VDP do interesting things, but only within the boundaries of what the VDP does. There can be clever tricks to do things mid-frame that it wasn't initially intended to do, but those tricks don't extend to making it have a bitmapped mode or be able to draw bitmaps scaled or rotated.
  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: Wed Mar 23, 2022 3:31 am
Yes, POC. With a side scrolling shooter or first person game template, I can start adding these effects.

If I have to build from scratch using the devkitSMS, then everything will be in C and carry some overhead. With less control, it's unlikely that I would get something that rivals Road Rash, let alone any of the 3D arcade ports.

Almost anything can be done at a low frame rate or low resolution, but that's not going to give people the effect of moving down a track or any other high speed game.

And using 8x16 sprites would allow coverage of about 1/3 of the screen with smooth moving sprite-textures, but most of the 3D effect has to be accomplished with animating background tiles, color cycling, line interrupts, etc.

I've really got to have an existing game to work with that's written in Z80 Assembly. And there are neither first person nor side scrolling shooters in the Homebrew section.
  View user's profile Send private message
  • Joined: 23 Aug 2009
  • Posts: 213
  • Location: Seattle, WA
Reply with quote
Post Posted: Wed Mar 23, 2022 4:59 am
SavagePencil wrote
start writing some code, dude


If it’s slow, that’s solveable. Write some code.
  View user's profile Send private message
  • Joined: 04 Jul 2010
  • Posts: 539
  • Location: Angers, France
Reply with quote
Post Posted: Wed Mar 23, 2022 7:23 am
Quote
If I have to build from scratch using the devkitSMS, then everything will be in C and carry some overhead. With less control, it's unlikely that I would get something that rivals Road Rash, let alone any of the 3D arcade ports.


Sorry to be rude, but that's a total nonsense...Hi level things like that must be only done in full ASM.
But you can use SDCC/Smsdevkit with inlined ASM.

A basic "side scrolling shooter" from scratch is just a few hours thing not a week monster. If you can dev complex 3D things, making a pseudo 8bit first person (like the Phantasy Star dungeon) or a shooter is nearly a joke in comparaison.

You've already spent so many hours to speak/write things... stop and use this time to code your idea and make our eyes shining.
  View user's profile Send private message
  • Joined: 01 Feb 2014
  • Posts: 844
Reply with quote
Post Posted: Wed Mar 23, 2022 10:13 am
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.
  View user's profile Send private message
  • Joined: 05 Jun 2010
  • Posts: 757
  • Location: Pennsylvania, USA
Reply with quote
Post Posted: Wed Mar 23, 2022 1:38 pm
Kagesan wrote
It's still very confusing what you're aiming at. On one hand you're talking about polygons and 3D maths, which imply "real" 3D graphics that the SMS is ill-equipped to produce, then suddenly you're talking about pseudo-3D games, sprites, and parallax scrolling. Those are fundamentally different things that aren't the least bit alike.

You also ignore everything that seasoned developers keep telling you about VDP bandwidth, sprite limitations and screen modes. Instead you insist that "it can be done, because it has been done on [insert hardware that's completely different from the SMS]".

My suggestion: 1. Define exactly which effect you want to achieve. 2. Code a proof of concept demo of it.


Agreed, I think this guy just wants someone else to do it. There's a lot of talk and no action here. It's good to be enthusiastic and try new ideas, but until you try and see we'll never know and this conversation will continue to go around in circles.

NB: I am not trying to sound rude or to dissuade from attempting any of this. It is true, there are not many homebrew devs in the SMS community versus say, Vectrex, 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.
  View user's profile Send private message Visit poster's website
Reply to topic Goto page 1, 2, 3, 4  Next



Back to the top of this page

Back to SMS Power!