Inside3D!
     

Suggestions for performance upgrades to the Makaqu codebase
Goto page 1, 2  Next
 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> Engine Programming
View previous topic :: View next topic  
Author Message
JasonX



Joined: 21 Apr 2009
Posts: 89

PostPosted: Mon Jul 05, 2010 11:28 pm    Post subject: Suggestions for performance upgrades to the Makaqu codebase Reply with quote

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
View user's profile Send private message
leileilol



Joined: 15 Oct 2004
Posts: 1321

PostPosted: Tue Jul 06, 2010 12:08 am    Post subject: Reply with quote

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
View user's profile Send private message
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Tue Jul 06, 2010 12:52 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
mk



Joined: 04 Jul 2008
Posts: 94

PostPosted: Tue Jul 06, 2010 1:10 am    Post subject: Reply with quote

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
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 909

PostPosted: Tue Jul 06, 2010 1:19 am    Post subject: Reply with quote

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 ( Twisted Evil ) 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
View user's profile Send private message Visit poster's website
JasonX



Joined: 21 Apr 2009
Posts: 89

PostPosted: Tue Jul 06, 2010 1:54 am    Post subject: Reply with quote

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
View user's profile Send private message
mk



Joined: 04 Jul 2008
Posts: 94

PostPosted: Tue Jul 06, 2010 2:18 am    Post subject: Reply with quote

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
View user's profile Send private message
leileilol



Joined: 15 Oct 2004
Posts: 1321

PostPosted: Tue Jul 06, 2010 5:04 am    Post subject: Reply with quote

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
View user's profile Send private message
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Tue Jul 06, 2010 12:17 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
mh



Joined: 12 Jan 2008
Posts: 909

PostPosted: Tue Jul 06, 2010 12:38 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
JasonX



Joined: 21 Apr 2009
Posts: 89

PostPosted: Tue Jul 06, 2010 10:51 pm    Post subject: Reply with quote

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
View user's profile Send private message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Tue Jul 06, 2010 11:33 pm    Post subject: Reply with quote

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
View user's profile Send private message
mk



Joined: 04 Jul 2008
Posts: 94

PostPosted: Wed Jul 07, 2010 1:49 am    Post subject: Reply with quote

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
View user's profile Send private message
JasonX



Joined: 21 Apr 2009
Posts: 89

PostPosted: Wed Jul 07, 2010 1:59 am    Post subject: Reply with quote

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
View user's profile Send private message
mk



Joined: 04 Jul 2008
Posts: 94

PostPosted: Wed Jul 07, 2010 2:33 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    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