Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

Suggestions for performance upgrades to the Makaqu codebase Goto page 1, 2 Next

| Inside3d Forums Forum Index -> Engine Programming

View previous topic :: View next topic
Author | Message
--- | ---
JasonX Joined: 21 Apr 2009 Posts: 89 |

Posted: Mon Jul 05, 2010 11:28 pm Post subject: Suggestions for performance upgrades to the Makaqu codebase |

Hello all, I'm working on a Makaqu port to really low-end hardware, under software mode. I chose Makaqu over ToChris or vanilla WinQuake due to it's improvements, specially the nicer animation (interpolation) and menus. Unfortunately, there's something bringing the engine down in terms of performance. Maybe the transparencies? So, i would like to know how can i tune the engine to run as fast, and good, as possible? Disable transparencies, lighting styles, etc?

Back to top |

leileilol Joined: 15 Oct 2004 Posts: 1321 |

Posted: Tue Jul 06, 2010 12:08 am Post subject: |

Put in some assembly. Makaqu's improvements don't always include assembly equivelants. Have a virtual low screen resolution based off waterwarp's screen buffer code, sans warp. This is super fast already. You also might look into the lcd_x code for another way to do low detail or even just simple line skipping.
less dynamic light animation rates, this makes it better on 486s
_________________

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Tue Jul 06, 2010 12:52 am Post subject: |

If you're using a compiler that has some profiling tool, use it. You may be lucky and find some unexpected, easy to fix hot spot in the code. _________________ frag.machine - Q2K4 Project http://fragmachine.quakedev.com/

Back to top |

mk Joined: 04 Jul 2008 Posts: 94 |

Posted: Tue Jul 06, 2010 1:10 am Post subject: |

Quoting my answer to your pm:

Quote:
These settings may help: // console con_alpha 0 // either 0 or 1 scr_conspeed 999999 // default 300 // HUD
crosshair 0
sbar 3
sbar_show_bg 1 // only works with sbar 1, 2, and 3
// blending
sw_stipplealpha 1
r_sprite_addblend 0
r_particlealpha 0
r_wateralpha 1 // either 0.5, or 1
r_skyalpha 0 // zero or 1
// 3D rendering
r_light_style 0
r_waterwarp 0
d_subdiv16 0
vid_stretch_by_2 1 // Windows only
Try switching each one of these to see which ones give the best results for you.

However,

sbar 3 takes too much screen space in lower resolutions, so you may want to set it to either 2 or 1;
r_skyalpha doesn't make much of a difference when set to 1, so you may want to set it to 1;
and setting r_wateralpha to 0.5 may also be desirable if you don't want to lose water translucency.

leileilol wrote:
Put in some assembly. Makaqu's improvements don't always include assembly equivelants.

Actually, the only improvement that was also coded in x86 assembly is the transparent pixel color index for alias models, and that only happened because I examined the .spr rendering functions to learn what to change.
Despite of this, my x86 assembly skills are pretty much non-existent, so I can't optimize things further at the moment.
I'm aiming primarily for stability and consistency now, so there shouldn't be many speed improvements and new features until version 2.0.

leileilol wrote:
Have a virtual low screen resolution based off waterwarp's screen buffer code, sans warp. This is super fast already. You also might look into the lcd_x code for another way to do low detail or even just simple line skipping.

I've already had countless headaches trying to do both of these, but once the 3D renderer's refactoring takes place they should be easy to do.
The best thing that came out of my studies about lcd_x was the stereo 3D rendering code, and it's very buggy.

leileilol wrote:
less dynamic light animation rates, this makes it better on 486s

Maybe. Disabling dynamic lights completely, as in GLQuake, may also be an option.
_________________
Makaqu engine blog / website.
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.

Back to top |

mh Joined: 12 Jan 2008 Posts: 909 |

Posted: Tue Jul 06, 2010 1:19 am Post subject: |

Well how many people actually run a 486 as their regular machine in 2010? OK, I know if you still have one and you use it for some retro-kick fetish ( ) you'll want good performance on it, but seriously... Optimizing for 486 performance is the wrong thing to be doing right now. Get it running reasonably well on a machine that managed to outlive the Brontosaurus first, then worry about 486s if you think there's return on investment in it for you.
With the software renderer I've found that a major bottleneck lies in writing pixels to the screen buffer. I don't know if Makaqu has done it, but getting rid of the SciTech MGL, writing a native DirectDraw (depending on your OS) driver, and unrolling some of the loops that write to screen can give major benefits.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

JasonX Joined: 21 Apr 2009 Posts: 89 |

Posted: Tue Jul 06, 2010 1:54 am Post subject: |

I'm not really targeting old PC's, guys, i'm planning to get a clean and fast codebase so i can port it to interesting hardware, such as the GP2X. I don't want to mess with GL support for those ports, my idea is to have a codebase as unified as possible, with mostly IFDEFs for different platforms.

Back to top |

mk Joined: 04 Jul 2008 Posts: 94 |

Posted: Tue Jul 06, 2010 2:18 am Post subject: |

mh wrote:
With the software renderer I've found that a major bottleneck lies in writing pixels to the screen buffer.

Yes, and reading pixel data from the video RAM can be even much slower, so one of the things I'm going to do is to turn the waterwarp buffer into a generic screen buffer.
This will also benefit screen writes, since there will certainly be no overdraw to the video RAM.

mh wrote:
I don't know if Makaqu has done it, but getting rid of the SciTech MGL, writing a native DirectDraw (depending on your OS) driver, and unrolling some of the loops that write to screen can give major benefits.

That's on my list of things to do, along with a redesign of the Video Modes menu.
_________________
Makaqu engine blog / website.
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.

Back to top |

leileilol Joined: 15 Oct 2004 Posts: 1321 |

Posted: Tue Jul 06, 2010 5:04 am Post subject: |

mh wrote:
Optimizing for 486 performance is the wrong thing to be doing right now.

But 486 is easier and shorter and more direct to say than "Intel 486DX4 / AMD5x86 / AMD K5 / Cyrix 5x86 / Cyrix 6x86 / WinChip". These machines all perform around the same in Quake because they are not Pentiums. Quake's pentium specific code fails on all of these.
Yes, a Cyrix 6x86MX 200 isn't far at all from the 486 performance when it comes to Quake. Shocking, I know! A Pentium 100 WIPES THE FLOOR of all of them! Anyway, if you make it faster on those it'll be faster on anything else.
As for assembly, Hexen II, Vavoom and Quake2 are all good leeching for patchwork adaptation.
_________________

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Tue Jul 06, 2010 12:17 pm Post subject: |

leileilol wrote:

mh wrote:
Optimizing for 486 performance is the wrong thing to be doing right now.

But 486 is easier and shorter and more direct to say than "Intel 486DX4 / AMD5x86 / AMD K5 / Cyrix 5x86 / Cyrix 6x86 / WinChip". These machines all perform around the same in Quake because they are not Pentiums. Quake's pentium specific code fails on all of these.
Yes, a Cyrix 6x86MX 200 isn't far at all from the 486 performance when it comes to Quake. Shocking, I know! A Pentium 100 WIPES THE FLOOR of all of them! Anyway, if you make it faster on those it'll be faster on anything else.
As for assembly, Hexen II, Vavoom and Quake2 are all good leeching for patchwork adaptation.

Ok, then: "Optimizing for 486DX4 / AMD5x86 / AMD K5 / Cyrix 5x86 / Cyrix 6x86 / WinChip performance is the wrong thing to be doing right now".
The Intel architecture changed a lot since this generation of CPU's. Things that used to be the best practice in terms of performance aren't now, because there are too many new factors acting here, like several levels of built-in CPU cache, hiperthread support, multiple cores or multimedia instruction sets (MMX, SSE) that weren't available then.
EDIT: Besides, Quake was never meant to run on this class of machine. The target hardware was the Pentium 100 with at least 8Mb of RAM. The 486 wasn't even officially supported because the lack of the FPU in many configurations.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

mh Joined: 12 Jan 2008 Posts: 909 |

Posted: Tue Jul 06, 2010 12:38 pm Post subject: |

leileilol wrote:
As for assembly, Hexen II, Vavoom and Quake2 are all good leeching for patchwork adaptation.

But absolutely correct about this point, all valuable resources that frequently get overlooked.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

JasonX Joined: 21 Apr 2009 Posts: 89 |

Posted: Tue Jul 06, 2010 10:51 pm Post subject: |

I'm porting Makaqu to GP2X and Wii right now. I don't want to stress myself yet with platform-specific code, such as input, since it will be the hardest part. I'm focusing on getting the engine running smoothly. I tested Makaqu also on flash, using the qbism port, and got no so smooth results. Compared to how vanilla WinQuake performs on those same platforms, it's very slow and that's what i want to change.
I'm using Makaqu 1.3 as a base and it's a little messy right now. There's a lot of Dreamcast code lying around, as well some strange stuff. That's why i wanted you guys help for what to optimize, what can be fixed or improved.

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Tue Jul 06, 2010 11:33 pm Post subject: |

Well ... MH's software interpolation code is blindingly fast. And easy to implement. Uses no asm. Totally portable. IF you are getting ok performance with WinQuake, you would think that you would also get ok performance with MH's software interpolation.
Tutorial: Software Quake MDL Frame Interpolation
Software Quake Transform Interpolation
Makaqu has a ton of awesome stuff like skybox support, some great QC extensions like scale, but if the only thing that you are really after is interpolation ...
[p.s. qbism added decals and some other stuff to his modified Makaqu engine. Those could be factors as well. I seemed to get very satisfactory performance with qbism's engine in Flash.]
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

mk Joined: 04 Jul 2008 Posts: 94 |

Posted: Wed Jul 07, 2010 1:49 am Post subject: |

I haven't checked mh's interpolation code, but the one in Makaqu is an improved version of ToChriS' interpolation code. I can't remember all the improvements at the moment, but one of them is certainly the timed framegroups. Most Quake engines with interpolation doesn't interpolate framegroups correctly.
Another was custom interpolation time intervals through QC, and IIRC there was also something about interpolation during demos.

Baker wrote:
[p.s. qbism added decals and some other stuff to his modified Makaqu engine. Those could be factors as well. I seemed to get very satisfactory performance with qbism's engine in Flash.]

Hmm, thanks for mentioning. I'll take a look at its source even before trying to port the next releases to Flash then.

JasonX wrote:
I don't want to stress myself yet with platform-specific code, such as input, since it will be the hardest part.

Sometimes it can be really fun; the Dreamcast controller code was really nice to work with, except for the Jump Pack vibrations which were a matter of trial and error to adjust.

JasonX wrote:
I'm using Makaqu 1.3 as a base and it's a little messy right now. There's a lot of Dreamcast code lying around, as well some strange stuff. That's why i wanted you guys help for what to optimize, what can be fixed or improved.

Things like controller vibration will get abstracted in the next versions, to reduce platform-specific code and make it easier to implement those features in other platforms.
_________________
Makaqu engine blog / website.
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.

Back to top |

JasonX Joined: 21 Apr 2009 Posts: 89 |

Posted: Wed Jul 07, 2010 1:59 am Post subject: |

Yes, maybe it's smarter to port stuff from Makaqu to a clean WinQuake codebase instead of trying to fix Makaqu, but i failed to port the Skybox code, for example. There are comments, but the amount of code lying around is confusing, even with diffs.

Back to top |

mk Joined: 04 Jul 2008 Posts: 94 |

Posted: Wed Jul 07, 2010 2:33 am Post subject: |

Fixing the bugs is actually easier, and I'm working on it. _________________ Makaqu engine blog / website. Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> Engine Programming | All times are GMT Goto page 1, 2 Next
Page 1 of 2

Jump to:

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 vote in polls in this forum

Powered by phpBB © 2004 phpBB Group