0.051 Source Available

[CARPEDIEM]

Well it works just fine now, it still runs at 7.8 so i think we can release it.<br>Perhaps an sh3 build could be released and see if the bug is still there. what do you think?<br><br>The other mips versions can be removed too since this one is much much better.<br><br>Last modification: CARPEDIEM - 03/15/01 at 14:06:30

[Jaybot]

Right on! Now, I guess we just have to wait until it's all posted.  Dan, carpe (and everyone else), keep up the good work, you kick ass!

[Moose or Chuck]

When can we expect a release? I'd like 7.3 +/- FPS.

[Dan East]

Hmm. How fast was it with the other rendering routine? I hoped the problem was not with the new R_EmitEdge_fxp function, because it was very difficult to debug and convert to fixed point. It gains 1 fps on the iPaq. I would have to debug on a MIPS device to fine tune the precision.<br>Change the line in r_draw back to:<br>#ifndef USE_PQ_OPT1<br><br>Then go into quakedef.h and comment out:<br>#define USE_PQ_OPT1<br><br>You make pick up a fraction of a fps with that (cuts out some fixed point pre-conversions used by R_EmitEdge_fxp).<br><br>Dan East

[CARPEDIEM]

Well, i already tried that and i didn't get a speed increase. But don't worry dan, using the emitedge function that we are using only slows it down by 0.1 fps so it's cool.<br><br>Dan, if i could change the audio routines so that we could get like 0.3 fps more, could you support it and use that extra speed increase to make a build with 22050 hz sound?. Of couse, at no noticiable sound quality loss.<br><br>Last modification: CARPEDIEM - 03/15/01 at 15:14:21

[Dan East]

Yeah, those pre-conversions don't cost much.<br><br>I don't know how you're going to pick up .3 fps optimizing the sound routines, but if you can I won't complain! Of course if it sounds like an Atari 2600 when you're done then that would not be cool. <br><br>Dan East

[Dan East]

Carpediem; I'm currently working on another fixed point conversion, which I expect to increase FPS substantially. It will require that R_EmitEdge_fxp be used. If you've got time to continue on this project, you may want to debug on the device and try to see what's up with R_EmitEdge_fxp failing. Again, I hope for a pretty big jump in FPS, and I don't want the MIPS devices to be left totally in the dust.<br><br>Dan East

[CARPEDIEM]

I'll work on it tonight then and see what i can find.<br>A quick intro to fixed point conversions would help me a lot, I think im gonna have to understand this function this time so if you have the time i'd really like to learn.<br>

[Dan East]

Well, the actual fixed point math should be fine, as it works under both the emulator and on the iPaq. It is just integer math, so there won't be precision type problems unique to the processor.<br>Obviously there is some threshold that is being broken. From your description, rendering is perfect, except in certain rooms. If you can identify what occurs in those areas, opposed to the areas where the rendering is good, we can then fix the problem.<br>One thing to look for in particular is overflow. You'll recognize this if you get a negative or positive value when you shouldn't. Examples of overflow would be multiplying two large positive values and getting a negative result. Basically if the sign is not what it should be after an operation, overflow occured. That is the type of threshold event I imagine is occuring which distorts the rendering like flipping a switch.<br><br>Dan East

[randall]

Does anyone know what causes the "warped wall" effect, and if so, is it going to be fixed eventually?

[999]

That warping is from some kind of perspective correction routine which was disabled.  I'm not quite sure exactly what was done, but the trade off in speed was well worth it.<br><br>

[Dan East]

I've already converted the perspective correction routines to fixed point for 0.06. It slows the framerate down by 0.8. So unfortunately, Jacco's first optimization (the only one used by PQ) gained most of its performance by not doing something, as opposed to doing something better.<br>I've converted other routines to fixed point which increases FPS by at least 2, so that at least offsets the perspective correction addition.<br><br>Dan East

[randall]

It looks like someone jacked d_subdiv16. Normally this is a [fairly ineffective] toggle that performs perspective correction every 16 pixels. <br><br>It looks like this was extended beyond 64 pixels, possibly 128, it's difficult to tell.<br><br>I know d_subdiv16 is just a console variable (toggle), but I don't have time to scour the source code for the function that actually performs the task.<br><br>Anyway, since we were previously discussing the GPL, does id software approve of this kind of optimisation?<br><br>Maybe I notice this more because of my playing style. I tend to "hug" the walls, something I learned while playing Infiltration (Unreal Tournament).<br>

[randall]

oh, Dan already responded before I got a chance to post my last response. So will the perspective correction be "correct"?

[CARPEDIEM]

Great Dan.<br><br>Anyway... i've been going though some of the code and i really can't find anything wrong.<br><br>I'll tell you what. You release source 0.06 and i'll make the proper changes in emitedge (i hope that's the function that's giving trouble) so that it uses floats again. It really didn't give us a lot of speed increase so that should do.<br>My hands are really tied, i don't know how to fix this, i've spent a few hours trying this and trying that and no success.<br>