HUCAST wrote:Hi. I'm the Game Designer of DUX, Redux.
I am now looking for a coder who can code a KOS based Framework for us.
We'll need this Framework to port or game The Ghost Blad from PC to Dreamcast.
We will do the port by ourselve but we need a Coder that has a clou about KOS, and using the GPU to display highres graphics.So we mainly need the Framwork to manage Texture and Sprites for Compression. So it can automaticly do the sprite and Texture managment.
With such a Framework weport the game more easy.
Hey there man thanks for helping keep the DC alive!
Previously I have written a Stream Buffer solution for streaming video frames to the PVR.
That was used for a video player I was working on, you can look at that source here:
viewtopic.php?f=36&t=103406&p=1045796&h ... r#p1045796
After reading up on PRT(Partially Resident Textures), I think I have some ideas.
http://www.anandtech.com/show/5261/amd- ... 0-review/6
My basic idea is to create a Texture Stream Buffer(TSB) of the maximum size in main RAM as well as VRAM, and handle all texture memory management(TMMU). In this model, there will only be one call to pvr_mem_malloc(pvr_mem_available()), done on initialization of the TSB. Generally, we have about 4mb of teture memory on the PVR when things are all said and done.
Basically, your only job would be to bind your sprites to the TSB. The textures should be mip-mapped for optimal performance, otherwise the TSB will have to mip-map the textures for you. This can be done easily by setting the mip-map option when generating the VQ texture on PC.
The amount of sprites bound would not be limited by VRAM, rather main RAM. The SH4 has 16mb main ram, so maybe 8mb could be reserved for the TSB.
The Sprites would be bound as a pointer to the TSB, so each time the Sprite is updated outside of the TSB, its coordinates will autonomously be updated in the TSB.
Each frame, the TSB will first check if the Sprite is On-Screen. Assuming your vertices are 2D coordinates in screen-space ( needing no transformation ), this will be a very simple check.
If the sprite is not on-screen, its texture will not be marked to be loaded into vram.
If the texture is on-screen, the TSB can use software mip-map detection by comparing the area of the texture
against the area of the sprite, and find the mip-map level of the texture that best fits the sprite.
For example, when mapping a 512x512 pixel texture onto a 128x128 pixel sprite on-screen, the TSB would only load the 128x128 level of the mip-map into VRAM, instead of loading the entire 512x512 pixel texture.
After all sprites are checked for needing to be loaded into VRAM, the TSB will go through the VRAM texture list and remove any textures that do not need to be loaded for that frame. Next, the TSB will check available texture memory, and possibly reduce mip-map levels if the textures needing to be loaded will not fit in VRAM, before actually transferring the needed texture data to from RAM into VRAM.
An example of my solution is say you have a player sprite, and a high-res scrolling background sprite.
As the player sprite will likely always stay on-screen, the player sprite will remain resident in VRAM, meaning the TSB will only need to copy the texture from RAM into VRAM one time.
The scrolling background sprite will stay on screen until it eventually scrolls off-screen. This means the TSB will load the texture into VRAM once, and the texture will stay resident until the sprite has scrolled off-screen, at which point the texture will be removed from VRAM by the TSB.
I could go into more detail, but I should probably stop there for now
Let me know if that makes any sense
That's great for loading data.
