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!
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! -> 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?
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!