forums.ps2dev.org

PeterM · Joined: 31 Dec 2005 Posts: 125 Location: Edinburgh, UK

Hey guys,

Sorry for the long post!

It's been a heck of a long time since Chris Swindle and I did a Quake release, but hopefully there are still some people out there enjoying it!

I've been spending a few hours lately on hardware rendering, but before I go down any dead ends, I wanted to check my assumptions with the GU gurus around here.

First off, the current state of Quake hardware rendering is this:

1. Based off GLQuake.
2. All GL calls have been commented out, and it doesn't crash. ;-)
3. Some GL calls replaced with GU equivalents, most things are rendered with random flat-shaded polys.
4. No texturing yet.
5. No clipping yet.

I plan on sticking with GLQuake's non-multitexture method of drawing the scene -- polys are generally sorted by texture and drawn in two passes, one for the texture maps, another for the light maps.

I need to clip the polys, since big ones (like walls, floors and large doors) often get culled by the hardware when they go outside the tiny guard band.

I'm a clipping noob, so any advice would be welcome!

Regarding textures, they are all 8-bit, and will either use a greyscale lightmap palette (unless the PSP has a luminance format?), or the standard Quake palette.

I would welcome any advice people have regarding texture management.

I can fit them all in RAM, but probably not in VRAM without quality loss. Polys are sorted by texture so VRAM thrashing hopefully isn't too much of an issue.

I'm planning on just doing a FIFO or LRU cache, where texture memory is split into chunks of some known size. Maybe 32x32 or 64x64 texels. Big textures would probably take up several blocks, and smaller textures would waste some space.

Swizzling can be done easily enough, but not until I verify that they're loaded and rendering okay.

Thanks for your time guys, sorry again for the long post.

Pete

rapso · Joined: 28 Mar 2005 Posts: 147

my first advice would be to convert the diffuse textures (which are probably 8bit-palettet) to dxt1, this has 4bit/pixel whick should cut the memoryusage for this to half (and allow you to make better usage of the vram).
the psp has no luminanz-texture support, but if the lightmaps are just luminanz-textures you just need to create one simple palette with grayvalues as colorentries, straight forward.

Maybe you could check first the amount of texturespace needed for diffuse and for luminanz-textures/lightmaps. this could help in giving you advices how to manage them ;)

I think I would put mipmaps into vram, as they're mostly used and just for the higher resolution textures use mainmemory, simple memorymanagement as well :)

PeterM · Joined: 31 Dec 2005 Posts: 125 Location: Edinburgh, UK

Hi rapso,

Thanks for the advice!

I'd not thought about using DXTC, I'll definitely look into that as it looks very useful indeed, especially given Quake's limited palette.

I agree that for lightmaps, 8 (or even 4-bit) textures may be the best approach. Maybe DXT1 could be a win here too.

You're right - I need to know how much memory they take up before I can manage them effectively. I guess what I'll do first is try to load them all into VRAM and see if I run out.

I'm currently using 32-bit display and draw buffers, but maybe these could be downgraded to 16-bit if needed and the quality difference isn't that big. Probably commercial games often use 16-bit too.

dot_blank · Joined: 28 Sep 2005 Posts: 498 Location: Brasil

32bit back/draw buffer always is best with
16bit front/display buffer ...this works magic and really
makes video memory effecient
_________________
10011011 00101010 11010111 10001001 10111010

PeterM · Joined: 31 Dec 2005 Posts: 125 Location: Edinburgh, UK

Wow, I never knew 2 different formats could be combined. How does double buffering work? Presumably the buffer pointers can't be swapped, since one of the buffers won't be big enough. Can the GE do a blit + dither?

Raphael · Joined: 17 Jan 2006 Posts: 646 Location: Germany

With dithering a 16bit display really isn't a image quality concern. Plus it saves you a lot of VRAM to use for textures, hence gives double speed improvement.

For VRAM texture caching I found LFU to be superior to LRU in certain cases, especially in scan-through cases as the Quake render path might create, since LFU soon degenerates to a static cache that holds the most 'important' textures and therefore saves the upload bandwidth. But I didn't test it with that specific environment, so it might be worse than LRU actually.

Regarding clipping, just be sure to read up on Sutherland-Hodgeman algorithm and it should be easy to get it working.
_________________
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl

rapso · Joined: 28 Mar 2005 Posts: 147

Raphael · Joined: 17 Jan 2006 Posts: 646 Location: Germany

PeterM · Joined: 31 Dec 2005 Posts: 125 Location: Edinburgh, UK

Thanks guys,

I was thinking about tessellation too, but I think McZonk had a problem doing that in Quake 2. IIRC he found that tessellating the polys to even small ones didn't quite solve the clipping issues, and generated a lot more geometry to draw.

I added some basic texture loading and management. I'm using 8-bit textures currently, and still a 32-bit framebuffer.

The frame buffers, depth buffer and textures take about 3MB, probably more for larger levels, but it looks like most of them will fit in VRAM with some tweaking.

Currently my approach allocates from fixed-size VRAM chunks, until there's none left, then allocates from system RAM using memalign(). It seems to work okay. I'll look into a VRAM cache later, but it may not be required if most textures fit in VRAM anyway.

GLQuake doesn't seem to free unused textures anywhere (unless I've missed it), so I'll need to find a good place to do that.

Thanks again for your advice.

P.S. Here are some "before and after" screenshots I made while working on texturing.

Textures seem really damn dark - I'll look into making them brighter.

noxa · Joined: 05 Aug 2006 Posts: 39

Sweet! What will your release policy be on this? Will you be posting up the code? I'd love to see how you handled all the texturing issues you've been discussing.

J.F. · Joined: 22 Feb 2004 Posts: 2906

PeterM · Joined: 31 Dec 2005 Posts: 125 Location: Edinburgh, UK

Indeed. When the binary is released, the source will be available too.
_________________
http://aaiiee.wordpress.com/

I can no longer do any homebrew PSP development nor discuss PSP specific topics.

noxa · Joined: 05 Aug 2006 Posts: 39

Well, I was looking for the source of the Super Mario War port the other day and couldn't find it - that's GPL. Unfortunately the GPL is not law, and even if it were most hobbyist developers would still ignore it. It's good to know that some people will follow it, but in general it's a pretty sucky situation. Thanks for clarifying your stance!

rapso · Joined: 28 Mar 2005 Posts: 147

ufoz · Joined: 10 Nov 2005 Posts: 86 Location: Tokyo

PeterM · Joined: 31 Dec 2005 Posts: 125 Location: Edinburgh, UK

Well, just like our previous Quake releases, the source code of this one will be available for anybody to download. I've never violated any license and I don't intend to.

Anyway, to help steer this thread back on topic, I'd like to ask about storing vertex data in system RAM. Does anyone know if there's a noticeable performance drop caused by not having vertices stored in VRAM?

Currently I allocate from display list memory using sceGuGetMemory, but would like to clip and store polygons in system memory.
_________________
http://aaiiee.wordpress.com/

I can no longer do any homebrew PSP development nor discuss PSP specific topics.

rapso · Joined: 28 Mar 2005 Posts: 147

Insert_witty_name · Joined: 10 May 2006 Posts: 376

There's no performance difference between having vertices in RAM or VRAM.

PeterM · Joined: 31 Dec 2005 Posts: 125 Location: Edinburgh, UK

Thanks. That saves some wasted time.
_________________
http://aaiiee.wordpress.com/

I can no longer do any homebrew PSP development nor discuss PSP specific topics.

cloudhunter · Joined: 17 Aug 2006 Posts: 86

PeterM · Joined: 31 Dec 2005 Posts: 125 Location: Edinburgh, UK

Thanks.

I've since gotten in touch with Chris Swindle, and this code is now in Subversion. There's still lots to do obviously, but I guess the code's there if people want an early peek!

(Please don't let it appear on DCemu or QJ as an unofficial release or alpha...)
_________________
http://aaiiee.wordpress.com/

I can no longer do any homebrew PSP development nor discuss PSP specific topics.

ataxy · Joined: 13 Apr 2007 Posts: 26

hi i have been hoping for an update of quake and of quake2 by mczonk but you are the first one that seem to show interest in updating there project, now i wish you good luck in this futur release but i would like to try out what you have done so far but i do not know how to compile file from a cvs, wich i think is what its called, so could anybody point me to a tutorial on how i could do it

PeterM · Joined: 31 Dec 2005 Posts: 125 Location: Edinburgh, UK

Hi ataxy,

If you're brave, the rough steps you need to follow are:

Download and install cygwin (I assume you're on Windows)
http://www.cygwin.com/

Install the PSP toolchain install script
http://wiki.ps2dev.org/psp:toolchain

Run it
(see above link)

Wait for it to download and build the toolchain

Download the Quake source using svn (Look at our SourceForge SVN page).
https://sourceforge.net/svn/?group_id=158726

Compile the Quake source
cd into the Quake/psp dir and type "make"

Success. Make sure you read the readme.html before posting "bugs".
_________________
http://aaiiee.wordpress.com/

I can no longer do any homebrew PSP development nor discuss PSP specific topics.

ataxy · Joined: 13 Apr 2007 Posts: 26

ok i got to this point

ATAXY@santa ~
$ cd psp-quake/quake/psp

ATAXY@santa ~/psp-quake/quake/psp
$ make
Makefile:221: warning: overriding commands for target `obj/HARDWARE/EBOOT.PBP'
/usr/local/pspdev/psp/sdk/lib/build.mak:178: warning: ignoring old commands for
target `obj/HARDWARE/EBOOT.PBP'
clipping.cpp
Assembler messages:
FATAL: can't create obj/HARDWARE/psp/clipping.o: No such file or directory
make: *** [obj/HARDWARE/psp/clipping.o] Error 1

ATAXY@santa ~/psp-quake/quake/psp

PeterM · Joined: 31 Dec 2005 Posts: 125 Location: Edinburgh, UK

mkdir -p obj/HARDWARE/psp
_________________
http://aaiiee.wordpress.com/

I can no longer do any homebrew PSP development nor discuss PSP specific topics.

ataxy · Joined: 13 Apr 2007 Posts: 26

thx a million it work, ill let you know of any bug i may notice that arnt allready explained in the read me and as you ask will not in any way post this as a release, unofficial, beta or wath ever title it could be given

on second note have you tought about looking into the quake2 port or your interrest are solely for the quake port

edit: ok i have tryed it out so far i must say i am trully impress in relation to the previous release texture are way cleaner and less pixelated but and this is the only one so far as i am not expiriencing any bug or slow down it seems like the texture are a bit to bright but aside from that absolutly no critic so far

Be3f · Joined: 15 Mar 2007 Posts: 59

PeterM - thx for the subversion, I'm going to compile it!

PeterM · Joined: 31 Dec 2005 Posts: 125 Location: Edinburgh, UK

PeterM · Joined: 31 Dec 2005 Posts: 125 Location: Edinburgh, UK

I've not really got time to work on anything else at the moment!

Be3f · Joined: 15 Mar 2007 Posts: 59

I'm playing the alpha right now and it is amazing!

Perfect graphics in 480x272 with bilinear texture filtering and proper polygon clipping, perfect underwater polygons rendering and awesome perfomance (slowdowns only in heavy-geometry scenes)...

Only particles dissapoint - they have incorrect (always black) color and slowdown framerate much.

Lightmapping will make the graphics much more eyecandy... :rolleyes:

I've found, that there is no V-Sync and no mipmapping in this build - Pete, try to test Quake with these things! With mipmapping perfomance will be higher, and textures that are far from the camera will be not too sharp (but, maybe, too smooth). I hope, mipmaps for 32x32 (mostly) textures will not eat too much memory...

Huge thx & GL!
_________________
00000110 00000110 00000110