1

A few months back I set myself the challenge of making a real-time rotating 3D cube on the Neo Geo AES/MVS. I have no experience of doing 3D so this will no doubt take me a while! But I have reached my first step.

My first polygon

1. Edge calculation (displayed using pixel-sized sprites)

9wefaCs.jpg

2. Fill the Polygon (Using a raster effect)

8cSPZhY.jpg

3. Another example

MRjwf6N.jpg

The "Polygon Engine" title is overly optimistic! I'm not sure how many polygons it could draw and remain fast. But anyway I am just making a cube for now

The polygon is filled using a raster effect (I move a prestored triangle up/down and left/right)

The program can currently draw a single polygon based on the vertex positions. It should be fairly easy to add more polygons. I will need 2 more for my 3D cube. Speed will be a big issue though. The edge calculation routine isn't that fast although I am working on optimising it now. When I get stuck I will ask for some help on this. I am not currently using interrupts - apart from one to start the fill routine - I just padded out each display line with NOPs but I will need to use interrupts to give more time to the program to calculate polygon edges.

I am using the standard DevKit. I use C for everything at the moment apart from the raster fill routine which is in assembler

Also want to say thank you very much to the people on this forum for helping me with coding problems when they have arisen. I will probably need more help soon smile

2

This is awesome!! Please keep us posted it will be cool to see your progress. What you are up to is over my head.

As I understand you only have something like 96 sprites so how the heck are you pulling off so many pixel based sprites? Refering to your first picture with your wire frame. Are you using 16x16 squares? How can you draw so many? Are you using taller sprites based on the calculated angle? Ex: 16x16 ranging up to 16x512 - This is magic to me!

I wonder if I'll be able comprehend what you are doing here lol. I love it!

3

a very clever idea for a filling routine on this hardware and I can imagine that it works well for a simple cube... if you can do it in 30fps and maybe even with a light source it would be really impressive!!! boing

4

Thank you very much for the kind words guys 🙂👍


Mega Shocked (./2) :
As I understand you only have something like 96 sprites so how the heck are you pulling off so many pixel based sprites? Refering to your first picture with your wire frame. Are you using 16x16 squares? How can you draw so many? Are you using taller sprites based on the calculated angle? Ex: 16x16 ranging up to 16x512 - This is magic to me!

There are 320 sprites on screen in that pic - you have 380 sprites on the Neo Geo so this is well within the Neo Geo's abilities. There is a 96 sprite limit per horizontal line though. I think I only have a maximum of 32 sprites on one line there (each pixel sprite is really a 16 x 16 character square). So yes no problem for the Neo Geo!

blastar (./3) :
a very clever idea for a filling routine on this hardware and I can imagine that it works well for a simple cube... if you can do it in 30fps and maybe even with a light source it would be really impressive!!! boing

Yes that would be something to aim for! I feel that it *may* be possible for me to to do the standard cube at 60fps if I work hard on it. But 30fps I think definitely

One good thing about this technique is that the raster filling routine itself is very fast. So if it was possible to pre-store all the edge positions - it would be able to display something like 25 polygons per display line at 60fps. It would be then be able to display some kind of polygon-based "cut-scenes". It has a lot of limitations though - horizontal sprite limit issues and polygon color change issues. It would need to be planned out very smartly. Getting the right-size pre-stored triangles etc

Not sure if the Neo Geo can store a lot of data though? Is it right that we only have a small space for the program and pre-stored data?

5


Not sure if the Neo Geo can store a lot of data though? Is it right that we only have a small space for the program and pre-stored data?

As far as I know P1 rom is 1mb but there are cases where where more than 1 P rom is used. As I understand it when you are bank switching for the purpose of accessing more C rom gfx data a second p rom is used. It would be cool to see what you uncover when you investigate it would be neat to better understand how these additional P roms can be used!

I wonder if you could store your 3D data in the c roms and read the data back somehow? I know that might be a lame curiosity its just there is alot of space to store gfx data maybe your data could be read back...

Thanks for your insights regarding the way you are using sprites! Very cool you are using 16x16 sprites. I always think in sprites per horizontal line I often forget the 380 sprites you have access to!

6

CosmicR:
Yes that would be something to aim for! I feel that it *may* be possible for me to to do the standard cube at 60fps if I work hard on it. But 30fps I think definitely

the longer I think about it, the more sure I am that 60fps is also possible! oui -> check your PM!

CosmicR:
One good thing about this technique is that the raster filling routine itself is very fast.

how can this routine be fast if you have to interrupt your code in every scanline to change the x/y position of at least one sprite? confus

CosmicR:
So if it was possible to pre-store all the edge positions - it would be able to display something like 25 polygons per display line at 60fps. It would be then be able to display some kind of polygon-based "cut-scenes". It has a lot of limitations though - horizontal sprite limit issues and polygon color change issues. It would need to be planned out very smartly. Getting the right-size pre-stored triangles etc

oh, 25 polygon, that's very optimistic!
the accuracy of the scanlines is only given on real hardware, most emulators (incl. MAME) have problems... it will look terrible with incorrectly positioned polygons and gaps between the surfaces... not to mention the amount of data that would be required. for your idea with polygon cutscenes it would be better to use a simple but optimised animation.

7

Mega Shocked (./5) :
As far as I know P1 rom is 1mb but there are cases where where more than 1 P rom is used. As I understand it when you are bank switching for the purpose of accessing more C rom gfx data a second p rom is used. It would be cool to see what you uncover when you investigate it would be neat to better understand how these additional P roms can be used!

I wonder if you could store your 3D data in the c roms and read the data back somehow? I know that might be a lame curiosity its just there is alot of space to store gfx data maybe your data could be read back...

Thanks for your insights regarding the way you are using sprites! Very cool you are using 16x16 sprites. I always think in sprites per horizontal line I often forget the 380 sprites you have access to!

Yes I worry a lot about the 96 sprite limit even when I don't need to. It does seem like it could always be a problem somehow! The one you have to watch out for is if you shrink a 512 pixel high sprite to the minimum height - for the purpose of the horizontal sprite limit, it will still count as 512 pixels high.

I̶ ̶t̶h̶o̶u̶g̶h̶t̶ ̶t̶h̶e̶ ̶s̶a̶m̶e̶ ̶a̶s̶ ̶y̶o̶u̶ ̶-̶ ̶m̶a̶y̶b̶e̶ ̶1̶m̶b̶ ̶o̶r̶ ̶2̶m̶b̶ ̶f̶o̶r̶ ̶t̶h̶e̶ ̶P̶ ̶r̶o̶m̶.̶ ̶B̶u̶t̶ ̶w̶h̶e̶n̶ ̶I̶ ̶l̶o̶o̶k̶e̶d̶ ̶i̶t̶ ̶u̶p̶ ̶o̶n̶ ̶t̶h̶e̶ ̶t̶e̶c̶h̶ ̶w̶i̶k̶i̶ ̶i̶t̶ ̶s̶e̶e̶m̶s̶ ̶t̶o̶ ̶o̶n̶l̶y̶ ̶b̶e̶ ̶6̶8̶k̶?̶?̶ ̶(̶1̶M̶i̶b̶ ̶=̶ ̶1̶ ̶m̶e̶b̶i̶b̶y̶t̶e̶ ̶)̶ ̶W̶h̶i̶c̶h̶ ̶i̶s̶ ̶p̶o̶o̶r̶ ̶f̶o̶r̶ ̶s̶u̶c̶h̶ ̶a̶ ̶g̶r̶e̶a̶t̶ ̶c̶o̶n̶s̶o̶l̶e̶ ̶a̶s̶ ̶t̶h̶e̶ ̶N̶e̶o̶ ̶G̶e̶o̶ ̶:̶)̶ ̶I̶ ̶g̶u̶e̶s̶s̶ ̶i̶t̶ ̶c̶o̶u̶l̶d̶ ̶b̶e̶ ̶b̶a̶n̶k̶ ̶s̶w̶i̶t̶c̶h̶e̶d̶ ̶b̶u̶t̶ ̶i̶t̶ ̶w̶o̶u̶l̶d̶ ̶n̶e̶e̶d̶ ̶a̶ ̶l̶o̶t̶ ̶o̶f̶ ̶b̶a̶n̶k̶s̶ ̶t̶o̶ ̶s̶t̶o̶r̶e̶ ̶a̶n̶y̶t̶h̶i̶n̶g̶ ̶l̶a̶r̶g̶e̶.̶ ̶M̶a̶y̶b̶e̶ ̶I̶ ̶a̶m̶ ̶w̶r̶o̶n̶g̶ ̶h̶e̶r̶e̶ ̶t̶h̶o̶u̶g̶h̶?̶?̶

EDIT : Sorry I read that quickly and got it completely wrong! It said "the 68k P-Rom" and of course it was referring to the 68000! smile But *it is* 1 Mebibyte which is apparently a fraction more than a Megabyte in size - 1048k instead of 1024k (for 1 Megabyte). Like you say it can be bank-switched.

https://wiki.neogeodev.org/index.php?title=P_ROM

That would be a great idea to store in the C-Rom - but you can't read it with the CPU on the Neo Geo MVS/AES. (As far as I know!) Maybe the Neo Geo CD could do this though.

--------------------------------------------------------------------------------------------------------

blastar (./6) :
the longer I think about it, the more sure I am that 60fps is also possible! oui -> check your PM!

Thank you for your message! Sorry I didn't know I had a message before. I have replied now 👍

how can this routine be fast if you have to interrupt your code in every scanline to change the x/y position of at least one sprite? confus

I see what you mean there but I meant in a case where you have all edges pre-stored. You don't need to use interrupts at all. You can give the display fully over to the raster routine. That is how my program currently works - no interrupts apart from one to start the raster routine. You would have to make sure you always draw the same number of polygons every line - some can just be turned off or moved away with the y reg if not needed.

oh, 25 polygon, that's very optimistic!
the accuracy of the scanlines is only given on real hardware, most emulators (incl. MAME) have problems... it will look terrible with incorrectly positioned polygons and gaps between the surfaces... not to mention the amount of data that would be required. for your idea with polygon cutscenes it would be better to use a simple but optimised animation.

This was my thinking : you can fit a max of 32 polygons (X and Y writes) on a display line. If you take a few of those away for setting up the x and y address once each and the modulo once at the start of the line and maybe some other issues - I thought 25 would be fair. If you had to actually change palette colors in the hblank though that would reduce it a lot. I would try to avoid doing that. Thinking about it you might want to change the modulo once more each line. Maybe 20 polygons is possible per line?

EDIT : I should have said my idea was to have a number of different-sized pre-stored sprite triangles at regular intervals in VRAM so they can be jumped to using the same modulo. Maybe with one modulo change. Is very brute force! And tough to set up the right colors.

Yes that's true about a pre-made animation - Was it HPman who converted the Bad Apple demo? I guess that is the best way to do this polygon cutscene idea - all pre-made. It would have been nice to see some real polygons though. I was reading on computers like the Amiga they will often just feed the blitter a load of edge segments to do polygons ultra-fast now. That's kind of similar. But they are very short animations.

And yes I agree about the edge data being too huge really. It would be a lot!

8

*Deleted*