Dreamcast-Talk.com

Also there nothing stopping any one giving back to the scene and fixing any thing that is wrong with kos and submitting updates it's not dead or anything.. opensrc is the best way to go so the scene stays alive we can all try to fix any bugs we find or improve kos..

Anthony817 wrote:That is some next level big brain shit right there. What are you writing the game in? What kind of libraries are you using to create the game? Like Bleem using their own libraries independent from the official Katana, Windows CE and KOS SDK's, this project of yours is all the more impressive considering the graphical fidelity you achieved with a 2D game on the DC. I always said it looked like high quality flash or something similar.

It's about 90% C code,10% C++. Newlib for standard C stuff, everything else is custom.

The quality of the graphics is largely owed to the following:
- Simplified VRAM layout. In order to gain speed and efficiency (in this case - it could be less efficient for other games), I dropped support for texture sizes other than 256x256. Because all textures are now the same size, memory fragmentation is no longer an issue.
- Texture compression. The game needs more textures than the VRAM can hold. All textures are stored in RAM in compressed form. When a frame is about to be rendered, any textures that are required but not present in VRAM, are quickly decompressed and stored in the least recently used VRAM address. This is all handled within the VRAM management code, to avoid having to write several layers of managers on top of each other.
- Palette handling. Rather than using the 4 global palettes, each texture can have its own unique palette. How? Well, the PVR supports VQ-compressed textures, in which a single byte references 4 pixels via a lookup table. But Neill Corlett, who was working with us in the early days of RRRR, pointed out that this can also be used in another way. We store the palette entries in the VQ lookup table, and tell the PVR that our 256x256 textures are 512x125 pixels. That means that the PVR scales down the textures, displaying only 1 pixel for every byte, instead of the 4 intended by VQ compression. This effectively gives us regular indexed-colour textures. The colour quality per palette entry is not quite as good (effectively only 16 bits each, versus 32 bits in the global palettes), but because there are so many more colours to work with, the overall image quality is greatly improved. Besides, it is still possible to use the global palettes (although I find they tend to render slower).

Ian Micheal wrote:Nice work Kos is fine it has limits most of all is sound no DSP mixing proper .. Main problem i have with kos projects is sound not video or speed of the video system direct pvr with some inline asm is as fast as katana

To be fair, I also depend on the CPU for sound mixing. An attempt was made by Neill Corlett to write a version that could run on the ARM processor instead, but for some reason it only worked in debug mode and was never completed. I'm OK with that, though. Audio mixing doesn't demand much of the CPU, especially since I only need about 8 voices for a game like this.


Sorry if this was OT, but I figure someone will probably find this stuff interesting.

Roel wrote:

Anthony817 wrote:That is some next level big brain shit right there. What are you writing the game in? What kind of libraries are you using to create the game? Like Bleem using their own libraries independent from the official Katana, Windows CE and KOS SDK's, this project of yours is all the more impressive considering the graphical fidelity you achieved with a 2D game on the DC. I always said it looked like high quality flash or something similar.

It's about 90% C code,10% C++. Newlib for standard C stuff, everything else is custom.

The quality of the graphics is largely owed to the following:
- Simplified VRAM layout. In order to gain speed and efficiency (in this case - it could be less efficient for other games), I dropped support for texture sizes other than 256x256. Because all textures are now the same size, memory fragmentation is no longer an issue.
- Texture compression. The game needs more textures than the VRAM can hold. All textures are stored in RAM in compressed form. When a frame is about to be rendered, any textures that are required but not present in VRAM, are quickly decompressed and stored in the least recently used VRAM address. This is all handled within the VRAM management code, to avoid having to write several layers of managers on top of each other.
- Palette handling. Rather than using the 4 global palettes, each texture can have its own unique palette. How? Well, the PVR supports VQ-compressed textures, in which a single byte references 4 pixels via a lookup table. But Neill Corlett, who was working with us in the early days of RRRR, pointed out that this can also be used in another way. We store the palette entries in the VQ lookup table, and tell the PVR that our 256x256 textures are 512x125 pixels. That means that the PVR scales down the textures, displaying only 1 pixel for every byte, instead of the 4 intended by VQ compression. This effectively gives us regular indexed-colour textures. The colour quality per palette entry is not quite as good (effectively only 16 bits each, versus 32 bits in the global palettes), but because there are so many more colours to work with, the overall image quality is greatly improved. Besides, it is still possible to use the global palettes (although I find they tend to render slower).

Ian Micheal wrote:Nice work Kos is fine it has limits most of all is sound no DSP mixing proper .. Main problem i have with kos projects is sound not video or speed of the video system direct pvr with some inline asm is as fast as katana

To be fair, I also depend on the CPU for sound mixing. An attempt was made by Neill Corlett to write a version that could run on the ARM processor instead, but for some reason it only worked in debug mode and was never completed. I'm OK with that, though. Audio mixing doesn't demand much of the CPU, especially since I only need about 8 voices for a game like this.


Sorry if this was OT, but I figure someone will probably find this stuff interesting.

No this was great thank you food for thought

Just what I wanted to know! Thanks!

Saw a few people mentioning similar topics in here so I figured I'd check in.

I am interested in adding C and Z button support to SF3 Third Strike to act as additional L and R inputs. Reason being that I am using a Saturn Virtua Stick Pro (HSS-0130) with two Tsunaident 123 Saturn->DC adapters and the buttons that would normally be HP and HK are mapped to C and Z rather than L and R. So far, every arcade/fighting game I've tested has worked flawlessly, treating C and Z as additional L and R inputs, with the exception of Third Strike.

Was hoping someone would be able to point me in the direction of modifying 3S to treat C and Z as L and R. Normally I would just open the case and swap the buttons in question, but the combination of the HSS-0130s relative rarity and Sega's decision to solder the buttons directly to a PCB rather than use a wiring harness has put me off the idea.

Another thought I had was using an Arduino or similar to act as a sort of converter, automatically intercepting the C and Z inputs and forwarding them as L and R data, but I have not started to dig into the idea more. Just occurred to me as an option after building a DaemonBrite adapter and seeing how well that works.