PocketQuake FPM?

[esw]

Wow.. this is exciting! PocketQuake may get a speed boost! Now all you have to do is learn a little MIPS assembley... *pictures PQ at 50fps* *drools*

I think your work will be appreciated

[Robotbeat]

This thread belongs in the PocketQuake Developer Forum, but that doesn't exist, yet. (hint, hint, Chris Edwards/Matt!) I didn't want to get lost in all the other threads in the PQ forum, threads like "what's gx.dll?" and "PQ for Palm! Please?", so I thought that this was a more appropriate forum.

[Robotbeat]

I feel like a soldier without an officer right nnow . I need guidance from Dan as to what is needed. I think that more people should contribute to PocketQuake!

[Robotbeat]

Heck, anyone who knows more about the PQ source code than I do could help tell me what I can do!

[James S]

ESW, PocketQuake will never run at 50FPS until plenty after the XSCALE processor comes out. No amount of optimization can realistically increase the speed beyond 25 FPS on the current crop of devices.

Robotbeat, I've taken a look at the PocketQuake source, although I don't have it at the moment, I'm not even sure if I have eVC installed right now. But I could help you find your way around, and I could help you with the math with my Calc II knowledge if you'd like. ... But not now, I have this huge headache. I think the palmade I got from the hair dresser is causing it.

[esw]

yeah, I know. I was just joking about 50fps. Anyway, PQ is fairly optimized as it is. Randall's maps are fairly playable in landscape on an E-125, and so is the one I'm working on right now. It might be nice to have another FPS or two, though

[Robotbeat]

I know enough about math, I just need to know what file specifically could be optimized and give a performance increase. Especially I want to know what can be done without worrying about the other files. Is there any other math function that is slow? I love doing this type of math. I have programmed stuff on calculators to find the rest of the sides and/or angles of any triangle given any 3 other variables (well, you either need to give me ASA, AAS, SSS, or SAS. SSA took too long to program how to solve, so I didn't finish that one, yet.).

Dan, it sure looks like "#ifdef USEFPM" is used a lot. It seems like you attempted a quite global floating point to fixed point conversion of PocketQuake! Wow. So, I am assuming that you never got it to work, right? Do you think that someone (if not you) could get it to work? That would be a huge project just to understand all of that.

[Jaybot]

First of all, it's pomade.

Second of all, you never really need anything above trig to speed up quake.

Third of all, learn to program first. Then you would know how to look at a source code, and know what would need to be sped up. and also, you wouldn't have to ask Dan what to do every 5 minutes.

[Digby]

If you don't know how to profile the code, you're wasting your time. You need to profile the code, find the routines that are taking the most time, along with the routines that are called frequently, then spend your time improving those portions of code. It's also important to profile using the same code path through the application each time. Maybe you can use Quake's timedemo for this.

We have discussed a number of development topics over the last year in the PocketQuake forum. I personally think it's better to post PocketQuake specific dev issues there. While you might not want your thread to get lost in the plethora of "how do I install..."-type messages from newbies, it might be nice for the users to know that someone is considering performance improvments for the game. Heck, some might even volunteer to help you. It's your call though. I was just making a suggestion.

[Robotbeat]

Jaybot, I understand what you are trying to say, but if you are going to have multiple people working on the same project, then you need to organize the work. I will learn right now what needs to be done in order to figure out what routines take longest. Thanks, everyone, for your input.

[James S]

[Dan East]

The act of converting to or from floating point / fixed integer requires a floating point operation.

Thus my last large optimization project was to convert all the model verticies to fixed point at load-time, and perform all math in fixed point throughout the rendering process. It is a reasonable thing to attempt, and is of course possible to implement. Search for USE_PQ_OPT3 for all the work that's been done so far on that conversion.

I was hoping for a 50% or so speed increase from that optimization.

Dan East

[randall]

yeah. we're all hoping for that.

[Robotbeat]

Thanks, Dan. That would probably make quake run good on my e115 (with overclock, autoexec tweaks, etc.), which would be nice with its awesome screen and good buttons.

Thanks, Moose, for defending me! I actually do know the very basics of C (no pun intended!), and really, programming itself is not hard, it's trying to do stuff like a global conversion to fixed-point, like Dan was (is?) doing. But since Dan knows the code best, I choose to ask him. Now I have an idea of what he is trying to do, so maybe I'll be able to get on the road to actually doing something useful with my time (specifically, playing Quake at a decent framerate during school ).

I'll be reading through my C programming book, if anyone wants me...