IceDigger said:How about Quad Core optimization?
The cache is finally working for the VDP2 cell mode (the one used in the bios). I had some transparency problem due to textures not being reloaded when the transparency bit of the screen was changed, but that's now corrected.
Performances are quite interesting in the current cache state, ie around 50 fps when the "Sega Saturn" text is displayed, and between 30 and 40 fps inside the cd player.
You might say it's not that fast, but actually as the whole page is displayed (ie 512*512 pixels) instead of just the visible part (ie 320*224 in that case), a lot of extra calculation is done, which slows down the display. Of course I'll change that in the future, but right now it's already faster than it was in the previous release, so that's a good start 🙂
Now that's the cache is running for cell mode, I'm now in the process of integrating bitmap mode to it ... I took the opportunity to redesign the way both modes are setup, and to put it in different functions.
My goal is to have the whole bitmap to be added as a single texture to the texture map. That implies to modify the texture class structure, as until now each VDP2 texture was considered to be 8*8.
Now the bitmap texture will just be considered as a big cell (up to 1024*512), and displayed like the others.
So what are the next steps ?
add bitmaps to the VDP2 cache
convert the other display modes to use the cache
test the cache speed, and improve it
That's all for now (but that's a lot, believe me 😛)
Before moving on to something else, I wanted to understand why Dracula X title screen still had some priority problems, as it shouldn't be happening with my new cache. After a bit of debugging, I was able to get to the origin of the problem : the sprite priority calculation wasn't done on the right register.
Now everything is correct, as you can see on the following screenshots (left one is from 0.40 version) :
I also tweaked the cd block a bit, changing some return flags, and now it doesn't get stuck anymore : it still doesn't play smoothly, but it gets to the end of the video without blocking the emulation.
Last but not least, I started working on the DSP. Nothing fancy just yet (adding memory and registers, getting to know how the beast work), but the hardest part was to get into it, so I guess I'm on the right track 🙂
Well, the title is maybe a bit strong, but this processor is a really complex piece of work ...
The disassembler is done, the interpreter skeleton is ready, and I'm done coding the Operation commands (24 opcodes).
I'm now working on the Load Immediate commands (11 opcodes), DMA, JUMP and LOOP commands will follow shortly (I hope 😛)
Understanding how the opcodes really work is difficult, mostly because of poor / erroneous documentation, and I won't be able to test anything until every opcode (and the main loop) is coded ... Timing must also be taken care of, as DSP clock is only half of the main SH2's ... so there's still a lot to do until I can get any sound during the logo assembly 😛
I've also started toying around with various UI libraries (finally 😛), and I think I'll chose Juce for the next UI overhaul ... primary testing with OpenGL gave good results, I'll have to fire up my image creation software to create some nice icons (ph34r my mad Gimp skiils 😀) I'll try to post some screenshots when I'll have something more tangible 😉
Until then ... have a nice day !
Last months, I've been working on Saturnin with one goal : going open source (yay)
So, after spending countless time on it, everything's done, and I finally moved my sourcecode to BitBucket (I'll get back to that point another time).
But there's still one thing to take care of (well amongst others), before opening the depot to the public : I need to choose a licence.![]()
Of course, there are constraints :
- the future version will use plug-ins, and I don't want to force anyone contributing one to provide its sourcecode
- some of the actual code used in Saturnin wasn't done by myself (the SCSP core is Stef's for instance, the 68K code is from either Turbo68K or Musashi) ... I will put it into separate dlls also, but that must be taken into account
-some other things that I don't remind now![]()
After looking into existing licenses, I think GPL is too restrictive to my point of view, but LGPL could be a good candidate.
As I'm pretty new to that kind of stuff, I'm seeking advice ... so If you have anything relevant to say about that, please leave me a comment.
Thanks !