Jake's Wiki of Things and Stuff

Links

Here's secret page

http://segatech.com/
http://www.ludd.luth.se/~jlo/dc/ (Look at powervr-reg.txt and ta-intro.txt)
- powervr-reg.txt
  - Cheap shadow
  - specular highlight
  - VQ Textures?
  - UV Textures?
  - ta_luminance
  - MODIFIER_VOLUME - cheap way to simulate shadows
  - DMA
- ta-intro.txt (tiling accelerator)
  - gouraud
  - specular highlight

PS2 Shading

Lego Star Wars
- Lots of shading, lighting, highlites, etc.

Shadows and Lighting

(nothing yet!)
Check out DC games - what kind of shadows & lighting do I see? (tony hawk, etc)
- Tony Hawk
  - No noticeable shading
  - Shadow under the man
  - All texture mapped
- Maken
  - No shading (only textured shading that doesn't change as people move)
- TrickStyle
  - Has shading! As you turn, shadows move, but it has nothing to do with the lights. Present, but not very good.
- Echo the dolphin
  - Has fancy shimmering effect - rocks & dolphin
  - Nice fog effects
  - I don't know how they do the shimmering effects... They are really awesome!
    - Animated textures?
    - Fog effects?
    - Messing with the alpha blending?
- Crazy Taxi
  - Nice looking lighting on everything (ambient?)
  - Shadows of nearby cars are done pretty nicely.
How would shading & lighting be done?
- Software?
- PVR/Reverse Engineering?
- Is it worth poking numbers into the unknown PVR values?

Trying to build KOS:

using buildcross-1.4 from http://stalin.thegypsy.com/
- Here's another alternative: http://www.consolevision.com/?Dreamcast:Development:Under_Linux
binutils-2.17
gcc-3.4.6
newlib-1.13.0
kos from svn, I think
It's putting it in /usr/local/dc
(./buildcross.sh dreamcast -all --- build sh stuff)
./buildcross.sh dreamcast -dc --- builds arm stuff, hopefully!
(./buildcross.sh dreamcast -k --- builds kos)

Those who need them can also go grab:

http://gamedev.allusion.net/softprj/kos/SDL/

Those should all be extracted from within the kos-ports dir you just 
downloaded above. They should create 'freetype', 'SDL/SDL_mixer' and 
'SDL/SDL_ttf', as well as a couple of things in include. Note that you 
will still need to change into each of those dirs and build those 
manually at the moment ("make" will suffice).

That didn't work, so for freetype/ttf I did:
- cp -R /opt/dc/kos-ports/include/freetype/ include/
- cp -R /opt/dc/kos-ports/SDL/SDL_ttf ./
- cp /opt/dc/kos/addons/lib/dreamcast/libfreetype.a ./
- cp /opt/dc/kos-ports/include/libmenu.h ./
- cp /opt/dc/kos/addons/lib/dreamcast/libmenu.a ./
- cp /opt/dc/kos/addons/lib/dreamcast/libSDL_mixer.a ./
- cp /opt/dc/kos-ports/include/SDL/SDL_image.h include/SDL/
- cp -R /opt/dc/kos-ports/SDL/SDL_image/ ./
- cp /opt/dc/?? libSDL_image.a kos/addons/lib/dreamcast/

So what do I still need?

Source code for the following that I can compile cleanly:
- freetype, libSDL_ttf, libSDL_mixer, libmenu

Dziokzit needs to be fixed up to work!

For Dziokzit to compile and run properly, I modified kos-ports/SDL/base/src/timer/dc/SDL_systimer.c:

void SDL_StartTicks(void)
{
        /* Set first ticks value */
        //start = jiffies;
  // Jake modified this by hand...
  start = timer_ms_gettime64();//jiffies;
}

Uint32 SDL_GetTicks(void)
{
  // Jake modified this by hand...
  //return((jiffies-start)*1000/HZ);
  return timer_ms_gettime64()-start;
}

Libraries

KallistiOS
KGL (3d graphics library built into KallistiOS)
- Theoretical max = 5000 polys per frame
- Better (maybe double) speed if you turn off the automatic Z clipping and only use triangle strips.
- With the pvr_dr_* funcs I've seen up to 3M pps, which is 50000 per frame. (Dan Potter)
- To get the full speed out of the low-level DC calls, you also have to do some wacky stuff like combine all your matrices together in the hardware registers and stream the vertices straight out of your model and into the 3D hardware (no intermediate memory storage). You can get some pretty decent performance if you do that, but it of course limits the flexibility quite a bit for special effects. What I'm basically saying is that to get full speed you must read your vertices once and throw them straight to the 3D processor. The only way KGL could do that is if it has some kind of vertex arrays support; I dunno if anyone ever added that or not.
KGL with DR (Direct Render) - from manual - 4 times as fast as regular KGL
- I strongly urge you to review the bubbles demo under the Dreamcast KGL examples.
- stuff from matrix.h, pvr.h, gl.h
SDL (built into KallistiOS)
- If you want to do graphics, you really are going to end up using 3D stuff one way or another, even if it's just to draw 2D objects. The DC is too slow to do it any other way.
Chui's SDL port (Supposed to be more updated than the regular SDL in KallistiOS)
- http://chui.dcemu.co.uk/sdl.html
KGLX (Enhanced version of KGL)
- 2002 - http://www.boob.co.uk/devtools.html
Holly (Used to be Iris3d) - SDK isn't available (yet?)
- Iris3d (2003): http://sourceforge.net/project/showfiles.php?group_id=66578
- Holly: http://a128.atspace.com/holly3d/
Tsunami and libParallax
- I wrote toolkits called Parallax and Tsunami for KOS and the DC a while back. Parallax is a basic graphics lib for doing close to the metal 3D without KGL, loading textures uniformly, etc. Tsunami is a C++ toolkit I added on top of that which adds transparent reference counting, a simple scene graph system, sound effects, etc.
Tiki - combines tsunami and libParallax
- Later on some others got interested in the idea, so I shipped over the source to them. Between Atani, Sam Steele, and Brian Peek, we now have ports for Linux, DC, and Win32 as well. So the long and short of it is basically that Tiki is an SDL-like toolkit, but with a bunch of extra stuff beyond the real basics SDL covers, and all written in C++. And of course somewhere in its bowels the drawing model is based on the PowerVR, so it's much easier to port stuff back to the DC with it. I'm actually doing any DC work these days in Tiki on my Mac and then porting it back over.
- n our public Subversion repo you can now find the Tiki toolkit, which is the result of my ripping various pieces of Tsunami, Parallax, and KOS out, and turning them into a pure C++ toolkit for OSX and Win32 game development. http://www.allusion.net/svn/kos/tiki/
- KOSX --?? mysterious ?? - KOS for Mac OS X?
  - Someone is doing some work right now to make KOSX use SDL so that it can be ported to non-OSX platforms. That'll probably end up becoming the "real" KOSX. Other than that I've not touched KOSX myself since R1. I've got Tiki now, which is something totally different that I'm planning to open source sooner or later...

The Win32 port is largely the fault of Brian Peek (of Ganksoft); and Atani, a member of the DC scene, has been cool enough to work on SDL, Dreamcast, and Linux support for Tiki, and hopefully those will be in place soon.

Good cross platform combos:
- Dan Potter:
  - - SDL for basic windowing system interface
  - - OpenGL for visuals
  - - OpenAL for audio
  - - SDL for user input
  - - Python for scripting
  - - Bits of KOS code in random places, on non-DC platforms
  - I guess for the average game the best way to go is still to make N front/back-ends for N platforms and tie them into the code that does the real work. If some of those can be reused (like OpenGL) then that's great.
- Sam:
  - If you don't plan on taking advantage of OS-specific features (native dialog boxes, for example), then SDL is still a good choice.
  - My final choice of libraries at the moment is:
    - Mac OS X: Cocoa, OpenGL, OpenAL
    - Windows: MFC, OpenGL, DirectShow
    - Linux: SDL, SDL_mixer, OpenGL
    - Dreamcast: KOS, KGL, Tremor

Other notes

I also believe there is more that Dreamcast can do graphically if we could change the way we approach it ie not so
I mentioned that the SH4 has fantastic floating point support. For example, it has single instructions to produce sin/cos and sqrt values which I believe execute in one or two clocks. It's also got full matrix multiplication instructions, which is way beyond anything the x86 or PPC has (as far as I know anyway). Even without an L2 cache, the SH4 is awesome at streaming huge chunks of verteces out of RAM, transforming them, and submitting them to the 3D chip. On the other hand, GC and Xbox have L2 caches on their motherboards, or I assume they do anyway, which will make them blow the DC out of the water for random RAM access speed.
The bottom line there is that if you are generating vertex data on the fly and sending it out to the PVR2, the bottleneck is the bus between the DC and the PVR2, which seems to top out around 2.2Mpolys/sec. If you use RAM also, it's maybe best to do the streaming transform thing and use DMA to dump it to the PVR2 since that at least doesn't tie up the CPU doing the transferring (and it is free to start on the next frame, do AI, whatever).

Interesting tidbits from the manual

You can have KOS automatically initialize subsystems if you want them to be active during your program. For example, you will probably want IRQs to be active in your program. On the other hand, you might not want threading active.3.2. KOS_INIT_FLAGS(INIT_DEFAULT); For example, on the DC, this constant enables IRQs and pre-emptive threads.

    * KOS_IMG_FMT_NONE - Undefined / Unknown
    * KOS_IMG_FMT_RGB888 - Interleaved r/g/b/ bytes (24-bit)
    * KOS_IMG_FMT_ARGB8888 - Interleaved a/r/g/b bytes (32-bit)
    * KOS_IMG_FMT_RGB565 - r/g/b 5/6/5 (16-bit)
    * KOS_IMG_FMT_ARGB4444 - a/r/g/b 4/4/4/4 (16-bit)
    * KOS_IMG_FMT_ARGB1555 - a/r/g/b 1/5/5/5 (16-bit)
    * KOS_IMG_FMT_PAL4BPP - Paletted (4-bits per pixel)
    * KOS_IMG_FMT_PAL8BPP - Paletted (8-bits per pixel)
    * KOS_IMG_FMT_YUV422 - y/u/v 4/2/2 (8-bit)
    * KOS_IMG_FMT_BGR565 - b/g/r 5/6/5 (16-bit)
    * KOS_IMG_FMT_RGBA8888 - r/g/b/a bytes (32-bit)

void* bfont_find_char(int ch)
- Returns the address in ROM of the given character, after being mapped to the BIOS font.
- void bfont_draw(uint16 *buffer, int bufwidth, int c)
- Draws Latin-1 character 'c' at the given location in 'buffer', and assumes that 'buffer' is 'bufwidth' pixels wide. For example, to draw an 'a' at 20,20 in a 640x480 framebuffer, you'd use bfont_draw(vram_s+20*640+20, 640, 'a').
- void bfont_draw_str(uint16 *buffer, int bufwidth, char *str)
- Exactly like bfont_draw, but it takes a string and draws each character in turn.
SPU: To use the processor you will need to write a seperate program that runs on the ARM7 RISC core and uses the AICA's own registers. This isn't covered in this document (or anywhere, to my knowledge). For some decent examples, though, take a look at ``s3mplay'' on the Cryptic Allusion DCDev site (see README).
Because of the tile system, there is no user clipping neccessary: the TA works backwards by intersecting polygons and volumes with each tile before rendering. The end result of all of this is that all you have to do as a user is cull out the completely useless polygons (if you feel like it), arrange things in polygon ``strips'' as much as possible, and then throw the various lists to the TA. Then sit back and wait for it to do its work.
The PVR chip is not magic: it is powerful and can accelerate the drawing process to an amazing degree, but it still draws in terms of screen coordinates. So it is really a fancy 2D accelerator with perspective correction support for textures, and z-buffering.
palettized textures are required to be "twiddled" (sometimes referred to as "swizzling"). This is the process of rearranging the texture samples in a special order for optimizing memory access for operations such as bilinear filtering. This means that the Y, U and V planes have to be twiddled before blending. Twiddling the subtractive V texture is optional as RGB565 do not have to be twiddled.
Software double buffering - render the screen in main memory, and copy it over using DMA or store queues