Anyone coding anything?
- Thread starter slinga
- Start date
Saturn seems to be very hard. I don't have any idea how to make a prog to use 4-5 processors at once...
You should start by sms or better genesis dev.
(because genny use only one proc with one vdp, and you can test your rom very fast using a emu).
And then go on saturn (saturn 2d VDP might me the *same* logic as the genesis one).
Oopps, spam!
I started my "floupix ping pong" one year ago, at the end of the 2003 sat dev contest (remeber lespin, the 3d multiplayer particle game ?) as a one week project.
One year later, it has been heavily tested and it is very fun to play. It's now time for me to release it and for you to play.
I provide the source code for all projects. My coding might not be the best possible, but I believe it is rather clear; and it actually displays what I want it to display.
Technically, floupix ping pong has sprites, backgrounds (thanks to vbt), sounds banks, data and audio cd acces, and even palette rotation.
Next project will be a multiplayer tank battle game.
I'll update the http://vieille.merde.free.fr (home of the ssmtf) soon with the floupix release.
One year later, it has been heavily tested and it is very fun to play. It's now time for me to release it and for you to play.
I provide the source code for all projects. My coding might not be the best possible, but I believe it is rather clear; and it actually displays what I want it to display.
Technically, floupix ping pong has sprites, backgrounds (thanks to vbt), sounds banks, data and audio cd acces, and even palette rotation.
Next project will be a multiplayer tank battle game.
I'll update the http://vieille.merde.free.fr (home of the ssmtf) soon with the floupix release.
mrkotfw
Mid Boss
i actually gave up saturn dev a long time ago because it was just a painful way to dev. i then started to write gba demos about a year ago and now i'm writing a platform game which is going very very nice! (and trust me, it's better than the 'meaw' demo i wrote a long time ago.)
Hi everybody!
EDITED:
I've attached 2 screenshots:
- a TV shot on Saturn(although it's gray, it is a RGB picture)
- a shot from mac version, the same renderer, but a colored image
Yesterday I finished my first working
version of a voxel-renderer for Saturn. I had problems with the scroll screen that did show up on Satourne, but not on the real Saturn hardware.
So listen up, Fabien. your emulator does not care about the RGB_Flag of BitMap scrolls. Thanks a lot for satourne, with XP now it's the first time that I get it to work and it helps a lot.
Thanks to vreuzon for his forum topic about using mkisofs for ISO creation on XP, because stripiso is not working. And yes, I did play Floupix several times and it's really fun!
The voxel-renderer I used is one of the fastest raycasting algorithms that I implemented in my diploma thesis.
Maybe this work was inspired by the impressive graphics of Amok(Saturn). I thought I can do better, and of course I could(todays computers are a lot faster, hehe).
But again, it's Amok that I admire. It's fast, it has 2 player screen(fast, too). And it combines its graphics with Sprites!! With correct occlusion!!
So far, I'm not very pleased with the result. It's a lot, and I mean really a lot, slower than I expected .
But it uses only one CPU(you can select Master and Slave), it got a damn slow C implementation of fixed mul and a damn slow fixed->float->divide->fixed division. It uses 16 bit RGB and a byte-by-byte workaround to insert the RGB_Flag after rendering.
The data transfer is everything else but optimized DMA.
The SCU DSP is unused, too(although it's difficult to find the right task for it).
All in all it's going to be a very interesting thing. I have setup a todo list to improve the speed and there sure is potential(also, there are some algorithmic modifications that I did not need to implement, because my PC/Mac was fast enough). But my measures showed only 4.16 FPS on a 50Hz Saturn and I'm convinced: the boys at scavenger did a real good job with Amok.
OK, I wrote too much, so just my question: anyone knows a good time to transfer Data to VDP2's VRAM? Is the VDP2 always accessing its VRAM? And I don't know all about slSynch(). Is it possible that I waste time with slSynch() because it got a wait loop inside?
Still reading? Then let me say you that 700 MHz of a poor G3 are able to render over 1080 frames per second and a even poorer K2-6 produces over 220 FPS with 500MHz. So these processors need 648 to 2.272 k cycles for one frame. So we sure can expect enough FPS on Saturn.
Stay tuned,
The Rockin'-B[attachmentid=843][attachmentid=844]
EDITED:
I've attached 2 screenshots:
- a TV shot on Saturn(although it's gray, it is a RGB picture)
- a shot from mac version, the same renderer, but a colored image
Yesterday I finished my first working
version of a voxel-renderer for Saturn. I had problems with the scroll screen that did show up on Satourne, but not on the real Saturn hardware.So listen up, Fabien. your emulator does not care about the RGB_Flag of BitMap scrolls. Thanks a lot for satourne, with XP now it's the first time that I get it to work and it helps a lot.
Thanks to vreuzon for his forum topic about using mkisofs for ISO creation on XP, because stripiso is not working. And yes, I did play Floupix several times and it's really fun!
The voxel-renderer I used is one of the fastest raycasting algorithms that I implemented in my diploma thesis.
Maybe this work was inspired by the impressive graphics of Amok(Saturn). I thought I can do better, and of course I could(todays computers are a lot faster, hehe).
But again, it's Amok that I admire. It's fast, it has 2 player screen(fast, too). And it combines its graphics with Sprites!! With correct occlusion!!
So far, I'm not very pleased with the result. It's a lot, and I mean really a lot, slower than I expected
.But it uses only one CPU(you can select Master and Slave), it got a damn slow C implementation of fixed mul and a damn slow fixed->float->divide->fixed division. It uses 16 bit RGB and a byte-by-byte workaround to insert the RGB_Flag after rendering.
The data transfer is everything else but optimized DMA.
The SCU DSP is unused, too(although it's difficult to find the right task for it).
All in all it's going to be a very interesting thing. I have setup a todo list to improve the speed and there sure is potential(also, there are some algorithmic modifications that I did not need to implement, because my PC/Mac was fast enough). But my measures showed only 4.16 FPS on a 50Hz Saturn and I'm convinced: the boys at scavenger did a real good job with Amok.
OK, I wrote too much, so just my question: anyone knows a good time to transfer Data to VDP2's VRAM? Is the VDP2 always accessing its VRAM? And I don't know all about slSynch(). Is it possible that I waste time with slSynch() because it got a wait loop inside?
Still reading? Then let me say you that 700 MHz of a poor G3 are able to render over 1080 frames per second and a even poorer K2-6 produces over 220 FPS with 500MHz. So these processors need 648 to 2.272 k cycles for one frame. So we sure can expect enough FPS on Saturn.
Stay tuned,
The Rockin'-B[attachmentid=843][attachmentid=844]
Attachments
I made some progress on the voxel-renderer.
The framerate now is between 5 to 12.5 FPS, depending on the number of pixels rendered.
Some details on changes:
Dual CPU usage now completely prepared, but not implemented yet
palette instead of RGB,
default terrain is colored now
double framebuffer in VDP2 VRAM using one RGB,
ASM fixed mul,
pixel transfer to VRAM evenly while rendering, not afterwards,
frame-2-frame coherence for clearscreen and pixel transfer,
a lot more flexible memory requirements(can reduce more),
pixels of a column are stored consecutively(like if image is turned 90 degrees),
Don't know why FPS scales so much with the number of drawn pixels, the number of steps the renderer performs is the same for all of above frame rates!
Note: have a look at Amok and you will see, that it draws just 1/3 of the screens pixels.
All in all: framerates become playable now!
But most of the work I did short after the last post is still unused.
Although it works (and speeds up) on PC and Mac, the LUT I want to use performs wron on Saturn.
The framerate now is between 5 to 12.5 FPS, depending on the number of pixels rendered.
Some details on changes:
Dual CPU usage now completely prepared, but not implemented yet
palette instead of RGB,
default terrain is colored now
double framebuffer in VDP2 VRAM using one RGB,
ASM fixed mul,
pixel transfer to VRAM evenly while rendering, not afterwards,
frame-2-frame coherence for clearscreen and pixel transfer,
a lot more flexible memory requirements(can reduce more),
pixels of a column are stored consecutively(like if image is turned 90 degrees),
Don't know why FPS scales so much with the number of drawn pixels, the number of steps the renderer performs is the same for all of above frame rates!
Note: have a look at Amok and you will see, that it draws just 1/3 of the screens pixels.
All in all: framerates become playable now!
But most of the work I did short after the last post is still unused.
Although it works (and speeds up) on PC and Mac, the LUT I want to use performs wron on Saturn.
I have now implemented dual CPU usage(the simplest sceme that came to my mind) for the voxel renderer.
Also, somehow the LUT works now for a certain type of configuration(remember: it's very flexible).
Three FPS rates I messured before increased now to:
5.55 -> 8.32
7.17 -> 9.96
12.5 -> 23.73
I have attached a screenshot from Satourne.
There you can see both frame buffers in RBG0,
because Satourne does not support some RBG transformations that I use.
[attachmentid=853]
(the stats you see must just for master CPU)
For an unknown reason, the display flickers and does not change to the 2nd framebuffer.
But it seems that the renderer does write to both frame buffers.
I need some experts advice:
As in a dual CPU communication example, I got a variable declared like this:
volatile void *ptr __attribute__ ((section("uncached")));
Now the strange thing is, that every write to this pointer
(not it's destination) does corrupt the first bytes of my sine LUT!!!!
I checked this a lot, both pointers point to different locations.
Workaround is to not declare
__attribute__ ((section("uncached")))
and then it works fine...
Any suggestions?
Also, somehow the LUT works now for a certain type of configuration(remember: it's very flexible).
Three FPS rates I messured before increased now to:
5.55 -> 8.32
7.17 -> 9.96
12.5 -> 23.73
I have attached a screenshot from Satourne.
There you can see both frame buffers in RBG0,
because Satourne does not support some RBG transformations that I use.
[attachmentid=853]
(the stats you see must just for master CPU)
For an unknown reason, the display flickers and does not change to the 2nd framebuffer.
But it seems that the renderer does write to both frame buffers.
I need some experts advice:
As in a dual CPU communication example, I got a variable declared like this:
volatile void *ptr __attribute__ ((section("uncached")));
Now the strange thing is, that every write to this pointer
(not it's destination) does corrupt the first bytes of my sine LUT!!!!
I checked this a lot, both pointers point to different locations.
Workaround is to not declare
__attribute__ ((section("uncached")))
and then it works fine...
Any suggestions?
Attachments
Thanks! The algorithm is a fences-style DDA(Digital Differenzial Analizer, like Bresenhams algorithm for rasterizing). For my diploma thesis I implemented also cells and 3D-step-vector method.
(with fences and cells I refer to the papers of Lee and Shin)
This gives a very flexible renderer toolkit that currently results in maybe 20-40 different varations of renderers. The one for Saturn is the simplest variant of the fastest algorithm of them. I will try others, too.
With the adaption to Saturn, I added some useful optimizations to reduze pixel clearing and memory transfer.
<!--QuoteBegin-antime
Rockin'-B, what link script do you use and how do you declare and use your pointer?[/quote]
I use the linking script that came with the SGL along with kpits gcc. The pointer points to the current framebuffer in VDP2 VRAM. It's value is reassigned after each rendering pass. Maybe I should check, if the pointers address in memory is identical to the first bytes of my sinetable.
