Quake2 And Mmu Hack


panu

Still Fresh
Joined
Jun 14, 2006
Messages
26
Just curious cause the current version (0.02) is almost playable when overclocked to 280 mhz...So Mmu hack might just be the "thing" that makes it playable...
 
Purist posted on Jul 5 2006 at 04:32 PM said:
Dang. I just switched to linux so I don't have any IDE to compile anything with.

What version of linux doesn't come with an IDE? :)

Oh wait where did mine go...:)

Back to the MMU thing.. Some one used the MMU hack in quake 1 with no luck. But heres hoping it will make a difference :)
 
Last edited by a moderator:
But presumably it does use the framebuffer, which the MMU hack also (can) be used to speed up. That's the only reason DrMD and SquidgeSNES get as big a boost as they do, iirc...
 
Would it at least boost the allotted memory to the engine? That might speed it up a few FPS. More allocated memory means a bit better performance, from what I recall from the DOS version.
 
Quake 1 plays wonderfully as it is now (OC'ed to 260). My only beef with it is the strafe buttons, what happened to L&R? The GP32 control layout was a tad better.

- Alex
 
Alex. posted on Jul 6 2006 at 02:12 AM said:
Quake 1 plays wonderfully as it is now (OC'ed to 260). My only beef with it is the strafe buttons, what happened to L&R? The GP32 control layout was a tad better.

Just edit the keymap in the config menu. I'm pretty sure mine defaulted to L/R as strafe, but I changed them to turning.
 
Last edited by a moderator:
IIRC, a lot of the choppy play and slowdown in Quake 2's '2x port was from reading the SD card as the full game content did not fit in the 32mb of lower memory? With full speed access to all 64mb, would it be more feasible to precache everything in advance and alleviate some slowdown? Or is the rendering workload the real problem?
 
The mmu hack doesn't enable a program to use the upper memory if it wasn't originally set up for it. For situations like this, the correct solution would be a linux kernel option to change the memory split so there's say, 48MB "low" memory and 16MB "high"
 
Tobriand posted on Jul 6 2006 at 01:04 AM said:
But presumably it does use the framebuffer, which the MMU hack also (can) be used to speed up. That's the only reason DrMD and SquidgeSNES get as big a boost as they do, iirc...
The hack doesn't speed up the framebuffer, it speeds up the upper 32mb. Hardware surfaces are stored in part of the upper 32mb which is why a lot of stuff will speed up, but quake 1 and 2 use software surfaces (which are a faster surface to use when directly accessing pixels).

Epicenter posted on Jul 6 2006 at 06:45 AM said:
IIRC, a lot of the choppy play and slowdown in Quake 2's '2x port was from reading the SD card as the full game content did not fit in the 32mb of lower memory? With full speed access to all 64mb, would it be more feasible to precache everything in advance and alleviate some slowdown? Or is the rendering workload the real problem?
As BradN says, the hack doesn't give normal full access to the upper 32mb it just makes it faster. Quake2 allocates one big block of memory so there's still going to be a maximum limit of less than 32mb. None of this really matters as the bulk of the slowdown is because of the rendering, not loading.
 
Last edited by a moderator:
woogal posted on Jul 6 2006 at 09:58 AM said:
Tobriand posted on Jul 6 2006 at 01:04 AM said:
But presumably it does use the framebuffer, which the MMU hack also (can) be used to speed up. That's the only reason DrMD and SquidgeSNES get as big a boost as they do, iirc...
The hack doesn't speed up the framebuffer, it speeds up the upper 32mb. Hardware surfaces are stored in part of the upper 32mb which is why a lot of stuff will speed up, but quake 1 and 2 use software surfaces (which are a faster surface to use when directly accessing pixels).

I'm pretty sure that Paeryn's SDL have the screen in the upper memory too. When I first try the hack with gngeo, I was using software surface only and it give 10fps increase. Using an hardware surface instead of a software one give an other 10fps increase (because blitting the surface to the screen is now done in hardware).

However, I did try to use the hack with Quake, and it didn't improve it. I guess that quake don't draw as much as gngeo to the framebuffer.
 
Last edited by a moderator:
pepone posted on Jul 6 2006 at 10:18 AM said:
However, I did try to use the hack with Quake, and it didn't improve it. I guess that quake don't draw as much as gngeo to the framebuffer.
Yeah, you'll find with Quake1 that at 200mhz removing all framebuffer writes completely only speeds things up by 0.2fps
 
Last edited by a moderator:
If anyone would know about boosts to the code, it's Woogal. *thinking* So the MMU hack is a no-go. I guess we can hope that when we get better access to the second CPU, that it'll be able to be used to get a bit more action. Perhaps using a bit of the upper memory for texture storage or something might help. I'm sure in time, we'll squeeze a couple more FPS out of it.
 
Good to know people are still working on this one....I thought quake 2 was forgotten because the newest version was released 14/11/2005.
 
Winterkid posted on Jul 6 2006 at 02:42 AM said:
If anyone would know about boosts to the code, it's Woogal. *thinking* So the MMU hack is a no-go. I guess we can hope that when we get better access to the second CPU, that it'll be able to be used to get a bit more action. Perhaps using a bit of the upper memory for texture storage or something might help. I'm sure in time, we'll squeeze a couple more FPS out of it.
Um, he isn't even using the hardware blitter (I think, correct me if I am wrong), I think many many optimizations can be made without even using the second processor.

Does Quake natively require a Floating Point Processor? Or has it been changed to fixed-point yet?

I would rather see Descent at the speed of Quake now, Descent is still a revolutionary way to play that still isn't in any mainstream game.

And, it needs no Floating point because it could run on a 386 :D.

but in 640x480 mode you had better have a 300mhz pentium :).
 
Last edited by a moderator:
nubie posted on Jul 6 2006 at 07:22 PM said:
Um, he isn't even using the hardware blitter (I think, correct me if I am wrong), I think many many optimizations can be made without even using the second processor.

Does Quake natively require a Floating Point Processor? Or has it been changed to fixed-point yet?
Not sure if you're refering to Quake 1 or 2 here, but most of these comments apply to both.

Yes you're right, it doesn't use the hardware blitter because it requires direct pixel access to the surface and with SDL that is always quicker with a software surface rather than a hardware one. Not all the code is fixed point, but the pocketquake guys converted a load of the main intensive functions from floating to fixed years ago. Since then none of the other arm ports have made any further fixed point changes which means either

1) all the people working on the ports are like me and don't know enough about fixed point to predict if there will be enough benefit for the amount of work

or (more likely I'd guess) 2) there are no more major speed gains to be had from converting more code to fixed point.

The current speed of Quake1 on the gp2x matches very closely (slightly higher in most cases) other arm handheld versions I've tried (a few pocket pc devices, and the zodiac version). My guess is we aren't going to see any impressive speed increases to Quake1 on the gp2x unless someone finds a way to use the hardware. I've hardly looked at Quake2 so I suppose it could be possible there are some improvements that could be made without using the hardware, but again it's speed seems to match pocket pc speeds and that hasn't been improved by anyone for years either (other than a recompile for the xscale processor, which doesn't really count).

Or the short answer : if there were many many optimisations that could be made without even using the second processor then they would have been done long before the gp2x was created.
 
Last edited by a moderator:
Thanks for the explanation, Woogal. That at least puts our minds at ease, regarding the possibilities. Here's hoping something later on might be discovered to help.

I feel better just knowing where we stand.
 
Back
Top