This site is no longer active and is available for archival purposes only. Registration and login is disabled.

STOP sacrificing visual quality!


STOP sacrificing visual quality!

Postby Phantom » Feb 26, 2001 @ 4:06am

Carpediem, dude,<br><br>I have been reading this 'ported to casio' thread, and I noticed that you get good frame rates by removing lots of stuff. HOWEVER: Please be more careful, some of your changes cause unneccessary artifacts. Example: You changed every 'float' to 'int' int 'CalcGradients', causing bad lighting of the gun models. Not a big deal, perhaps, but it just isn't neccessary. If you multiply by 1024 prior to converting to int, you get 'fixed point numbers'. In this case, 22.10, since you have 10 bits for the fractional part, and thus 22 bits for the integer part. Now, do you calculus, and once you're done, shift by 10 to the right. The result is again an integer number, but this time it's a lot more precise. This is what I am doing with the span code; it doesn't contain float math anymore, but still, it's just as accurate (apart from the intentionally removed perspective correctness).<br><br>The reason that I write about this this way is that it's going to be very hard to match your 44% speed increase without sacrificing visual quality. This means that people will expect more than can be offered; or, a constant race between the aesthetically correct version and a fast, but dirty version. This is not good.<br><br>If you really want to help to get Quake faster without sacrificing lots of quality, then please take a quick course in fixed point math. It will be very rewarding for all of us, and for you, of course.<br><br>About this TraverseWorldRecursive thing: This is the core rendering function, so it's not suprising that it takes up so much time. Optimizing it is not going to do you any good, since it calls lots of functions that use at least 29.9% of the CPU time. :)<br><br>Jacco.
Give me some good data and
I will give you the world
User avatar
Phantom
pm Insider
 
Posts: 913
Joined: Feb 21, 2001 @ 8:14am
Location: Houten, Netherlands


Re: STOP sacrificing visual quality!

Postby killzat - Mark » Feb 26, 2001 @ 6:55am

Yes I'd have to agree with you, we're going to end up seeing people comparing 'hacked to pieces' and 'not hacked' versions etc.<br><br>The idea of this is not to sacrifice quality and yet gain speed, FPM will get you quite far if you just learn it.
killzat - Mark
 


Re: STOP sacrificing visual quality!

Postby Phantom » Feb 26, 2001 @ 7:40am

By the way: I am NOT disappointed by Carpediem's coding skills, or whatever, in fact I think he's done a very good job. Instead, my point is that we should join forces to aim for speed WITHOUT sacrifycing quality FIRST. Then, if we have done everything, we might want to sacrifice some quality. But I tell you: It is THEORETICALLY possible to run Quake on an iPaq at 20fps, all time time. Why? Because the iPaq is a 200Mhz beast. Quake ran fine on a P90. IF we fix the calculus, wich is quite possible, albeit a rather daunting task, then we will have full quality, full speed. That is my point. Let's not go for the easy fps scores. Let's do the job right. That's not a matter of one dude coding better than the other, that's a matter of taste. And that can be discussed. Hence the name, discussion board. :)<br><br>Jacco.
Give me some good data and
I will give you the world
User avatar
Phantom
pm Insider
 
Posts: 913
Joined: Feb 21, 2001 @ 8:14am
Location: Houten, Netherlands


Re: STOP sacrificing visual quality!

Postby CARPEDIEM » Feb 26, 2001 @ 7:41am

A mips processor version can't handle all the details that you guys would want.<br>Hey Jacco you know D*mn well im just getting started with these things, and while you were away i tried to make it faster. When you make your own optimizations you bet im gonna dump mine and use yours.<br>Besides i didn't just screw up graphics, i changed lots of things in the code, probably most of them not very cpu intensive functions but in all i got some fps increase.<br><br>I don't believe casio users should have the same vresion than ipaq users. If i use ipaq'z current optimizations i get less than 5% speed increase. <br>Yes, you got that right, less than 5%<br>With the other optimizations that jacco sent me (lower graphical details and more stuff) this number goes up to 22%
CARPEDIEM
pm Insider
 
Posts: 514
Joined: Feb 24, 2001 @ 3:58pm


Re: STOP sacrificing visual quality!

Postby killzat - Mark » Feb 26, 2001 @ 11:07am

Yeah, detail options would be a clever idea, although that's going to be a task to implement it properly.<br><br>Dan, just one question, what command line can I use in the autoexec.cfg file to load quake in Landscape (RIGHT) from the start? Needed for my special autoexec.
killzat - Mark
 


Re: STOP sacrificing visual quality!

Postby Dan East » Feb 26, 2001 @ 11:49am

In some cases the user will be able to set a level, such as the max number of edges or surfaces to render. However, it will be more likely that the user will simply be able to toggle between a new optimized routine or the original code with no middle ground. That would be extremely easy to implement.<br>As for setting the video mode, I let that one slip by me. The current version does not respond to changes in the video mode var. I've already corrected the problem, and future versions will handle it properly. The usage is:<br><br>Portait:<br>vid_mode "0"<br><br>Landscape rotated right:<br>vid_mode "1"<br><br>Landscape rotated left:<br>vid_mode "2"<br><br>Dan East
User avatar
Dan East
Site Admin
 
Posts: 5264
Joined: Jan 25, 2001 @ 5:19pm
Location: Virginia, USA


Re: STOP sacrificing visual quality!

Postby Dan East » Feb 26, 2001 @ 1:52pm

Well, as I mentioned in another thread, it's unfortunate, and possibly unavoidable at this time, that there are two different versions of PQ out there just because of processor type. What's happening is that we have a large number of people out there that own devices that fall short (by not too much) of being able to handle a floating point-based Quake. While Quake is currently very playable on the iPaq, owners of other devices simply want something playable at almost any cost to quality.<br>I do agree with Jacco that quality must be preserved. My suggestion is that optimizations that result in loss of quality need to be user configurable. Adding in new Quake variables is extremely easy, so this would be the ideal mechanism to allow user control in this area.<br><br>A few big reasons why quality must be preserved:<br>1) Far more powerful devices will be in production very soon. These will run Quake extremely well at full quality.<br>2) I have been in discussion with ID Software (including John Carmack) over various legal and programming issues from the onset of this project. They are very, very sensitive (legally and otherwise) regarding Quake. Various modifications I had in mind that I ran by them resulted in a response similar to "you can do that, but you can't call it Quake anymore, and it cannot use the ID levels (even shareware) since it is not Quake". If the quality of the software is reduced (by stripping out / reducing rendering) ID Software will not like it, and may have trouble with it even bearing the Quake name.<br>3) I have been contacted by "the Handheld Computing Division for Intel", which is extremely interested in and actively following this project. They stated "since Quake is a quoted benchmark on the desktop world, it seems reasonable that Pocketquake could be a first cut metric for 3D performance of embedded chips." However, Pocket Quake can only fulfull this roll as a universal benchmark if it renders at 100% quality.<br><br>Again, I think the solution here is to add Quake variables that will allow the user to choose between high quality, low fps, or low quality, high fps. Please make the defaults high quality, and distribute an autoexec.cfg that sets the higher performance values. This will also let us merge this project back into one set of source files that will build for all the Pocket PC devices.<br><br>Dan East<br>Last modification: Dan East - 02/26/01 at 10:52:12
User avatar
Dan East
Site Admin
 
Posts: 5264
Joined: Jan 25, 2001 @ 5:19pm
Location: Virginia, USA


Re: STOP sacrificing visual quality!

Postby CARPEDIEM » Feb 26, 2001 @ 2:09pm

Ok, i agree, user configurable it's gonna be.
CARPEDIEM
pm Insider
 
Posts: 514
Joined: Feb 24, 2001 @ 3:58pm


Re: STOP sacrificing visual quality!

Postby CARPEDIEM » Feb 26, 2001 @ 2:48pm

Well, i think from now on im going to tell you what changes were made before posting a new version, What do you think dan?<br>Anyway this are the changes in version 0.041<br><br>1) Modified CalcGradients. The result is a 0.13 speed increase and some glitches when getting really close to the monsters and with the gun. I personally don't see a considerable decrease in quality.<br>2) removed sprites and the sky.<br>3) tons of small modifications through the code that caused no decrease in graphic quality whatsoever.<br><br>And that's all.<br><br>Notes:<br>Im not trying to take credit away from anyone, everone knows im just learning, im no pro or have a lot of experience in these matters. For the last two days i've been trough thousands of lines of codes to try and improve performance on mips devices. This is not easy at all for me, im trying my best and im sorry not to be up to your standards, from now on i'll just use whatever code you guys make and abandon my speed increase attempts. Version 0.041 should be removed from the server and version 0.04 too, since it is not the same source code that the ipaq source uses.<br>
CARPEDIEM
pm Insider
 
Posts: 514
Joined: Feb 24, 2001 @ 3:58pm


Re: STOP sacrificing visual quality!

Postby Dr. Phat » Feb 26, 2001 @ 3:19pm

Dan, speaking of landscape, have you done any work on that for MIPS?
Mike Greene
"Quanti est illa perna?" (How much is that ham)
User avatar
Dr. Phat
the <i>phattest</i>
 
Posts: 834
Joined: Jan 24, 2001 @ 4:46pm
Location: Vienna, VA


Re: STOP sacrificing visual quality!

Postby CARPEDIEM » Feb 26, 2001 @ 3:32pm

Ok i think im singning off.<br><br>I'd like to thank everyone for their support , you've been nothing but nice to me.<br>but i don't think i'll be in the pocketquake for pocketpc's effort anymore.<br><br>Take care everyone and keep up the good work.<br><br>But before saying goodbye i'd like to give one last suggestion for the programmers. Please, try making R_RecursiveWorldNode() FixedPoint. I truly believe that's where you you guys are gonna get the extra frames you want.<br><br>Goodbye, it's been a good experience.
CARPEDIEM
pm Insider
 
Posts: 514
Joined: Feb 24, 2001 @ 3:58pm


Re: STOP sacrificing visual quality!

Postby Dan East » Feb 26, 2001 @ 5:14pm

Jacco, Carpediem; all three of us missed it with the D_PolysetCalcGradients conversion. I starting trying to remove the visual errors resulting from Carp's code by converting it to pure fixedpoint, and after several attempts I was no better off. So I forced myself to quit hacking at the code a bit and took a look at the algorithm. If you look carefully, ID Software, in their infinite wisdom, used floats for the sole purpose of multiplying floats by the inverse of an int, instead of simply divinding ints (i1/i2==(int)i1*(1/(float)i2)). I suppose that x86 processors with a fixed point coprocessor (which was a requirement of Quake) may actually be faster at multiplying two floats than dividing two ints (I sure hope so, or else I have no idea what they were thinking). So I simply changed the floats to ints and divided in place of the inverse multiplication. This now yields 100% accuracy with no floats. Good job Carp for heading in the right direction - that was an ideal "dead end" function for conversion (maybe the only one in the whole Quake source).<br><br>Dan East
User avatar
Dan East
Site Admin
 
Posts: 5264
Joined: Jan 25, 2001 @ 5:19pm
Location: Virginia, USA


Re: STOP sacrificing visual quality!

Postby Dan East » Feb 26, 2001 @ 5:43pm

Carpediem, certainly no one, including the many Casio owners that now have Pocket Quake, want to see you abandon this project. Beyond improving the performance there are other issues, such as why the SIP won't stay up on Casios, that need to be debugged on the actual devices. This is yet another area of experience you can gain working on this project. :) I wasted a whole lot of time performing a global rewrite of the float math to fixed point. That's just the way goes sometimes  when you're in new territory. I just didn't have anyone to criticize me, or give me the "I told you so", because I was going solo at that time. So, I certainly hope you don't quit the project, because there are many more feats to be accomplished with this Quake thingy. Thanks!<br><br>Dan East
User avatar
Dan East
Site Admin
 
Posts: 5264
Joined: Jan 25, 2001 @ 5:19pm
Location: Virginia, USA


Re: STOP sacrificing visual quality!

Postby Phantom » Feb 27, 2001 @ 3:31am

Carpediem,<br><br>Please don't leave us now. You have given very valuable hints in the right directions, and my criticism about your speedups was definitely not intended to stop you from doing that.<br><br>About the CalcGradients stuff: Dan, could you please send me your version, I was hacking away at that, but I'm having some problems. By the way, this function is preparing some data for the span renderer (specifically, the texture projection matrix), wich is internally stored as floats right now. Did you remove that too? I mean, if the calculus in the gradients code is fixed point, there is no point in storing the results of that code as floats if you are going to convert it back to fixed point at the earliest convenience anyway. :)<br><br>- Jacco.
Give me some good data and
I will give you the world
User avatar
Phantom
pm Insider
 
Posts: 913
Joined: Feb 21, 2001 @ 8:14am
Location: Houten, Netherlands


Re: STOP sacrificing visual quality!

Postby Dan East » Feb 27, 2001 @ 6:51am

We may be talking about a different function then. I double checked and all the global variables set by this function are int. This is d_polyse.c, D_PolysetCalcGradients:<br><br>void D_PolysetCalcGradients (int skinwidth)<br>{<br>     int xstepdenominv, ystepdenominv; <br>     int p01_minus_p21, p11_minus_p21, p00_minus_p20, p10_minus_p20, t0, t1;; <br><br>     p00_minus_p20 = (r_p0[0] - r_p2[0]);<br>     p01_minus_p21 = (r_p0[1] - r_p2[1]);<br>     p10_minus_p20 = (r_p1[0] - r_p2[0]);<br>     p11_minus_p21 = (r_p1[1] - r_p2[1]);<br><br>     xstepdenominv = d_xdenom;<br>     ystepdenominv = -xstepdenominv; <br><br>     t0 = (r_p0[4] - r_p2[4]); <br>     t1 = (r_p1[4] - r_p2[4]); <br>       //TODO: Ceil has been removed<br>     r_lstepx = ((t1 * p01_minus_p21 - t0 * p11_minus_p21) / xstepdenominv);<br>     r_lstepy = ((t1 * p00_minus_p20 - t0 * p10_minus_p20) / ystepdenominv);<br><br>     t0 = (r_p0[2] - r_p2[2]); <br>     t1 = (r_p1[2] - r_p2[2]); <br>     r_sstepx = ((t1 * p01_minus_p21 - t0 * p11_minus_p21) / xstepdenominv); <br>     r_sstepy = ((t1 * p00_minus_p20 - t0* p10_minus_p20) / ystepdenominv); <br><br>     t0 = (r_p0[3] - r_p2[3]); <br>     t1 = (r_p1[3] - r_p2[3]); <br>     r_tstepx = ((t1 * p01_minus_p21 - t0 * p11_minus_p21) / xstepdenominv); <br>     r_tstepy = ((t1 * p00_minus_p20 - t0 * p10_minus_p20) / ystepdenominv); <br><br>     t0 = (r_p0[5] - r_p2[5]); <br>     t1 = (r_p1[5] - r_p2[5]); <br>     r_zistepx = ((t1 * p01_minus_p21 - t0 * p11_minus_p21) / xstepdenominv); <br>     r_zistepy = ((t1 * p00_minus_p20 - t0 * p10_minus_p20) / ystepdenominv); <br><br>     a_sstepxfrac = r_sstepx & 0xFFFF; <br>     a_tstepxfrac = r_tstepx & 0xFFFF; <br>     a_ststepxwhole = skinwidth * (r_tstepx >> 16) + (r_sstepx >> 16); <br>}<br><br>Last modification: Dan East - 02/27/01 at 03:51:00
User avatar
Dan East
Site Admin
 
Posts: 5264
Joined: Jan 25, 2001 @ 5:19pm
Location: Virginia, USA


Next

Return to Pocket Quake 1 and 2


Sort


Forum Description

Discuss Pocket Quake 1 and 2 by Dan East

Moderators:

Dan East, sponge, James S

Forum permissions

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

cron