Quake Video


Woogal

That rocks! Having not had a GP32 I can't comment but I have to say that this looks very playable. I figured that low frame rates would not look so good, shows what I know. Sorry for doubting.
 
Awesome work Woogal. Its been so long since i played Quake, that I just had a damn flashback watching that video! Cant wait to take this for a trip down memory lane. Its crazy how you can still picture exactly where to go in your mind, after all these years.

Do you plan on implementing configurable controls anytime soon?
 
Tbh, it doesn't surprise me that it looks comparable to the GP32 version atm - I played quake a fair bit at 200MHz on my Gp32 (one of the few that could reliably make it up there without adding extra lead to the contacts inside :D ), and it worked pretty slickly. And this version is, iirc, essentially a port of the GP32 version, and the core is set at 200MHz, so you know, somehow I'd have thought they'd probably look kinda similar.

THE main thing I'm interested in in terms of Quake, over and above battery life (200MHz on a Gp32 could last a while) and not killing the chip (200MHz was, imo, kinda pushing things a bit in terms of when the unit was likely to die), is the presence of the extra memory. Means mods might actually be sensible to run :D.

And Quake had a fair few of those, iirc :)
 
I would imagine it should be forkable -- copy the polygon display lists and such over to another buffer and kick off the second cpu to do the rendering; it'd be a frame behind then, but should speed it up a touch; not sure how much, since I imagine most of quakes time is spent doijng the rendering.. so moving the rendering to the other cpu would just make the first cpu mostlyu idle while the second is fully busy then.. so not a huge boost. Still....

(and I've not looked at doing this, so I'm only guessing at this point.)

Doing an even split between CPUs is a tonne of work though :/

jeff
 
wow, looking good woogal... how much optimizing have you done? used much of the 2D hardware support yet?
It's just a port of the gp32 version, so it includes all the stuff like the fixed point optimisations from pocketquake and the doublesize stuff I added to gpquake etc. It uses no special hardware.

Do you plan on implementing configurable controls anytime soon?
You already can configure them. The buttons are all mapped to various keys, so you just go to configure controls and set them however you want. The only button that can't be configured is Start.
 
Last edited by a moderator:
woogal: Looks awesome!

And to those who can't play the vid; download this and install:
http://md5.se/pub/misc/indeo511.exe

what is this windows crap :angry:
I have a mac and can't get it too run in VLC, Mplayer, or even quicktime.
What the heck is up with this video, I can run just about anything between the 3.

So will I be able to play this as soon as I get my gp2x? I can't wait to start playing quake.
 
Last edited by a moderator:
Too bad about that whole PPC nonsense reallynotnick ;-) My linux machine plays the video (though sadly without sound, and can't convert it to anything).

Looks like fantastic work, woogal, but maybe if you have the upper hand in the codec department, you could convert it to something a little more friendly? It would probably be better if someone else could do it, actually.
 
The video works fine with the MPlayer plugin on FreeBSD. Looks good, too. I'll echo the sentiment that "it's hard to believe it's only 11.5FPS".
 
I would imagine it should be forkable -- copy the polygon display lists and such over to another buffer and kick off the second cpu to do the rendering; it'd be a frame behind then, but should speed it up a touch; not sure how much, since I imagine most of quakes time is spent doijng the rendering.. so moving the rendering to the other cpu would just make the first cpu mostlyu idle while the second is fully busy then.. so not a huge boost. Still....

(and I've not looked at doing this, so I'm only guessing at this point.)

Doing an even split between CPUs is a tonne of work though :/

jeff


I remember devs that have kits saying that both CPUs can't access memory at the same time. That leaves the cache and wouldn't only 4K be useless for doing anything useful in quake?
 
Last edited by a moderator:
Cant you just stfu davec?
You are the most annoying guy on the forum, makeing the same statements 523957392 times a day and ignoring any responses that say otherwise.
 
Dave, there are many things that can be done. Popular systems have already been created that use multiple CPUs in the same manner.

It will take a while for these methods to become common knowledge. But eventualy, the idea will be to keep common functionality on the same CPU, so that there is as little communication between the CPUs. So Sound Processing on one CPU and Graphics on the other.
 
woogal- great work. Thanks.

Just wondering about overclocking. I take it this runs at 200mhz, but is there any chance of being able to overclock the first processor to say 250mhz? Or is this not possible at the moment for some reason?
 
Yes, this is clocked at 200mhz. Not tried changing the clock speed yet (not even sure if it will work with linux running).

Oh, and there is no sound ;). Partly because I couldn't be bothered connecting the headphone socket to my pc, and partly because at the time the sound was out of sync (fixed now though).

Davec : There is no need for both cpu's to be accessing memory at the same time. A second cpu is used to perform some task to free up the first cpu - they don't try and both do the same task together. As a real world example, think of the first cpu as someone doing the washing up, and the second as someone drying. The first cpu washes and puts the dishes to one side ready for the second cpu to put them up. The second cpu sits there waiting, then when a dish comes along it drys it and puts it away, leaving the first cpu free to wash something else. They never try and do something with the same dish as the same time. Just look at what skeezix wrote 'copy the polygon display lists and such over to another buffer and kick off the second cpu to do the rendering'. All the second cpu would do is pick up the data and render it. Once the first cpu has given the data away it doesn't care about it anymore.
 
Back
Top