Radquake Final Released

Ian Michael/Speud and Co have released a new version of RadQuake for the Dreamcast, heres whats new:[br][br] What's new ?[br]-----------[br]- converted SDL rendering to 2d PVR rendering (glitches in bottom left corner)[br]- implemented VMU support for config and state saving/loading (new cvars)[br]- modified the menu (fixed some bugs and added some submenus)[br]- implemented characters face display on the VMU's screen (loaded from a 144x160 1-bit image located in /cd/lcdicons.png)[br]- implemented rumble pack support (new cvars - only tested with Mad Catz's)[br]- modified Quake common functions to gain some speed (store queues)[br]- implemented a 50/60Hz display mode selector for PAL Dreamcasts[br]- implemented screenshots saving to PC (requires a coder cable or a BBA, screenshots are saved to /pc/radquake**.pcx)[br]- added extra icon for the VMU (ICONDATA_VMS)[br]- added extra background image for the boot menu (EXTRA.BG.PVR)[br]- implemented ability to move/resize the screen[br]- fixed the "quit" option so it leaves the application with DC-load[br]- implemented a main screen with a disc checking routine (it looks for /cd/QUAKE/ID1/PAK0.PAK) [br][br]Download from the RadQuake Page

An SBI is up at Sbiffy.

It was built with Sizious' SBI Builder. It was the first time I used the program, and I must say it is quite the handy little app. :)

posted :)

When we say final release does it mean they'res to be no more releases?

godknows

Seeing how theres at least 2 errors on release and one of which is a big deal I hope not. Saving errors sometimes and the rendering. And why does everyone switch to PVR rendering if its not giving speed ups? Because there doesnt seem to be perfect PVR yet.

basically, the idea is to cut SDL out of it. In all the few programs speud has put PVR rendering in, it does not actually use the PVR to render all the polys or lines, it does that in software, then uses the PVR directly to display it, instead of going through the framebuffer or SDL.

The lone exception would be BlackAura's new Genesis plus which actually uses the PVR to do some of the actual rendering as opposed to just screen display.

Actually, GP/DC uses the PVR hardware to do all of the rendering, not just some of it. The graphics are transferred over to video memory, then the PVR is used to draw all the backgrounds and sprites. As far as I know, no other emulator does that, but quite few of the homebrew games do.

Really, adding PVR 2D rendering to Quake does nothing. The only part of the display code which takes a lot of time is the part which copies the screen image from main memory to video memory, and converts it to the correct pixel format. Doing that manually tends to be faster than letting SDL do it, because SDL was designed to be very generic.

However, using the PVR to render the thing to the screen instead of just dumping it to the framebuffer gains no speed at all. It does let you move and scale the image without any speed penalty, but that tends to look ugly for 3D games.

Using real hardware acceleration would add a lot though. It'd be faster, and it could run at high resolution with texture filtering.

[quote author=BlackAura link=board=beats;num=1093469338;start=0#7 date=08/26/04 at 02:41:12]Actually, GP/DC uses the PVR hardware to do all of the rendering, not just some of it. The graphics are transferred over to video memory, then the PVR is used to draw all the backgrounds and sprites. As far as I know, no other emulator does that, but quite few of the homebrew games do.

Really, adding PVR 2D rendering to Quake does nothing. The only part of the display code which takes a lot of time is the part which copies the screen image from main memory to video memory, and converts it to the correct pixel format. Doing that manually tends to be faster than letting SDL do it, because SDL was designed to be very generic.

However, using the PVR to render the thing to the screen instead of just dumping it to the framebuffer gains no speed at all. It does let you move and scale the image without any speed penalty, but that tends to look ugly for 3D games.

Using real hardware acceleration would add a lot though. It'd be faster, and it could run at high resolution with texture filtering.[/quote]


sorry, i meant to say to do the rendering wasnt thinking, so i dont know how the some of got in there.