DCEmulation

SX is working on updating the Dreamcast port of OpenBoR for the v3.00 release. On the 'todo' list are things like RAM optimizations and new video modes (widescreen, high res, 16-bit, 32-bit).

I've pointed him to BlackAura's 2D graphics tutorial, but here's a question I obviously can't answer:

http://lavalit.com:8080/index.php?topic ... 5#msg31345

I think all he would have to do is look at an image library in the kos ports folder.

Here is a function copy&pasted from libpcx(pcx_texture.c) that I think would help give him some idea on how to do it:

afaik the port of BOR doesn't use KOS. Everything it does is from scratch, but the whole PVR setup required to do something like send a texture and such is quite complicated and would require a great deal of new hacked code to work.

You're correct, but OpenBoR v3.00 will use KOS.





- In the past there was a working KOS port but at some point we had to revert to Neill Corlett's bare bones library due to some reasons I can't remember right now.

A KOS port of BoR would mean an entirely new entity for Dreamcast users: easy to create compilations via DreamInducer, maybe FSL or the SandMenu, even DCHakker and DemoMenu could be used if you didn't want a graphic menu. But of course, who am I to speak, a mere Dreamcast user, and the Dreamcast port didn't do anything for the popularity of BoR did it?, wait a minute, do you think lavalit would even exist without DC (D.C.) .

Wait, wait, wait. So are you telling me that BoR is all software rendered? They aren't using the PVR? I never realized that.

Yep, BoR is all software rendered.

Those 2D tutorials I wrote were for software rendering as well, so they're not much use when dealing with the 3D hardware. Well, the mode setting stuff still applies, but nothing else does.

Basically, there's not much to uploading a texture to VRAM, even without KOS. If the texture is already in the right format, you just allocate some VRAM, and copy it over. KOS provides a VRAM allocator that works well enough for most things (pvr_mem_malloc), and functions to upload data to VRAM (pvr_txr_load). It's nothing like as complex as uploading a texture using OpenGL or Direct3D.

From memory, textures can be either 16-bit (ARGB1555, ARGB4444, or RGB565), 8-bit, 4-bit, or VQ compressed. For 2D graphics, VQ and RGB565 formats are kind of useless (ugly compression artifacts for VQ, and no transparency for RGB565), so you'd want to stick with the others. All texture dimensions must be a power of two, although you could pack multiple images into a single texture atlas to make better use of the space. Also, the 4- and 8-bit modes require that the textures be twiddled (KOS can do this, but it makes updating the image after you've loaded it much slower), and use a single shared colour palette with 1024 entries (64 separate palettes for 4-bit textures, or 4 separate palettes for 16-bit textures). The PSP, as far as I remember, can specify a different palette per texture, which makes it a lot easier to manage.

Bear in mind that you only have 8MB of VRAM to play with, and a lot of that is going to be used by the two framebuffers (~600KB each at 640x480) and the display lists (around 1.5MB with KOS's default configuration). That leaves you with slightly more than 4MB to play with, which isn't really a lot for animated 2D graphics. There might be some way to only upload parts that are actually being used, particularly for large character sprites. There are a few kinks involving deferred rendering (the cause of that weird graphics corruption problem in older versions of the GP/DC hardware blitter), but it can work quite well.

In KOS, once you have a chunk of allocated memory from pvr_mem_malloc, you can just pass that pointer to the rendering context functions (along with the texture format used) to make use of the texture. From there, you generate the display lists - one for opaque geometry (no blending, and no alpha channel in the textures), one for punch-through geometry (like alpha-test mode in OpenGL - use for textures with 1-bit alpha), and one for full blending (which renders much more slowly than the other two, so don't use it more than required).

I have a feeling that getting BoR to use the PVR for rendering would be much more difficult than getting the PSP's graphics hardware to do the same. It'd pretty much require run-time loading and swapping of textures, so it wouldn't alleviate the RAM limits that BoR currently has at all. It could even make them worse - if the graphics are 8-bit, but use far more colour palettes than the Dreamcast has, that'd force you to make the textures 16-bit, so they'd take up twice as much RAM.

Hello BlackAura, do you have more information about the 4 / 8 bit modes ? I'm still looking for using paletted textures in Dynamite Dreams. Thanks.

I think it can be interesting for BOR too, because, as far as I can remember, BOR uses gif textures, so it is in 8 bit paletted.
Perhaps, the community can build a gif support for KOS, which would be very useful.

Sure.

You've got a single set of 1024 colour palette entries to work with. If you're using 8-bit textures, that appears as four separate colour palettes. If you're using 4-bit textures, it appears as 64 colour palettes.

You can configure the colour palettes to store colours in either 16-bit (ARGB1555, ARGB4444 or RGB565) or 32-bit (ARGB8888). You then set each palette entry with the pvr_set_pal_entry function, which is set up for ARGB8888 mode, which is far easier to set up and use than the 16-bit modes.

The paletted textures are in two formats - 4-bit (PVR_TXRFMT_PAL4BPP) and 8-bit (PVR_TXRFMT_PAL8BPP). The basic format for 4-bit is two palette indexes per byte, with the first pixel in the upper 4 bits, and the second pixel in the lower 4 bits. The 8-bit mode is just a single 8-bit palette index per byte.

The paletted textures must be twiddled. The bit flag that switches twiddled textures on and off is re-used as a colour palette index for paletted textures, so the PVR assumes the textures are twiddled. If you upload the texture data using pvr_txr_load_ex, it can take care of that for you:

If you just use a paletted texture by substituting PVR_TXRFMT_PAL4BPP or PVR_TXRFMT_PAL8BPP for the texture format, you'll end up always using the first 16 or 256 entries in the palette. To get at the remaining palette entries, you need to use the the PVR_TXRFMT_4BPP_PAL or PVR_TXRFMT_8BPP_PAL macros:

That example will use a 4bpp texture, and the pallete #1 (indexes 16 to 31) instead of #0 (indexes 0 through 15). The same apples to 8bpp, except palette #0 is indexes 0 through 255, and palette #1 is 256 through 511.

It should be possible to do something similar with Parallax as well. If not, adding a couple of extra #defines to the headers will do the trick. I've never used paletted textures with Parallax before, just with the raw PVR API (in Genesis Plus / DC). I don't think Tsunami or any of the KGL variants support paletted textures, but it shouldn't be that hard to add support.