Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[dreiche2]

ah, seems you're right.

I had commented out the glaux lines earlier and then got some further error messages when linking, but it turns out these were unrelated (and fixed now after googling some more dependencies)...

so yeah seems to work now, thanks.


Edit: I give up for today. There are some weird things going on, though... well, at least weird to me.

Basically, I wanted to play around with some profiling program called shiny to see whether I can identify any hot spots in the computational load... so anyway, the weird thing is, when I include some test profiler calls in the mainloop, then suddenly my FPS doubles or triples?? Might be an artefact of high FPS, though, I had 1000 anyway. But nevertheless, the program really seems to run faster then.

Then, I can't see any profiler output because for some reasons std::cout doesn't seem to give any output. So I wanted to redirect it to a file, and apparently, when I open the file in the mainloop, my FPS boost goes away again... don't really understand what's going on there.

[dreiche2]

Toady, I don't know if you're interesting in feedback about minor things, but here it comes anyway.

I think you have some unnecessary calls to set the GL display matrices (or whatever they are called). As far as I remember they only need to be modified if something major changes about the display, and even then they not necessarily need to be reset completely.

Basically, I removed all glMatrixMode, glLoadIdentity, translate, gluLookAt etc. calls, from render_things, gridrectst (both in enabler) and from render_tiles (in graphics) without problems. Only in reshape_GL they had to stay.

It's hard to tell from that profiler thingie and the FPS counters, but I think I got a small performance improvement out of it (maybe 10% in the main menu). These things are probably not really the main issues with the code, but assuming the matrix calls are not needed, getting rid of them won't hurt.

[numerobis]

Basically, I wanted to play around with some profiling program called shiny to see whether I can identify any hot spots in the computational load... so anyway, the weird thing is, when I include some test profiler calls in the mainloop, then suddenly my FPS doubles or triples?

That's been reported for other reasons.  Seems like maybe the FPS cap isn't robust to certain stimuli, so the program blows past it in certain cases.  I couldn't figure out the flow of control in enabler_osx.cpp so I gave up because I've got code to write for work (usually I just do math, and want the occasional thing that actually runs, but having my off-time activity be the same as my work activity doesn't really work for me).

[mattmoss]

If you manage to navigate to a battle, you can get a pretty busy screen for testing.  You'd need to select your province ('a'), your army ('1'), move/attack (enter), select a province letter, then 'enter' to pass the turn.  Space to back out, esc to quit

Just for a bit o' fun... I built this on Mac OS X 10.4.11 (MBP), release build, fired up Shark and watched a battle.

Just over 70% of the CPU is in gridrectst::render(), and most of that is due to immediate mode OpenGL. (See http://www.devmaster.net/wiki/Immediate_mode). This is basically what I expected to see, although with DF's extra AI/pathing/etc work, render() wouldn't be quite so high. Still, that's gotta be a nice chunk to speed up. At the moment, I only have a relative measure, and didn't turn on FPS;... I'll have to look at it a bit more this weekend.

But... if you can rearrange things into arrays (which you may already have as such, or can be tweaked a little), then you could make use of glDrawArrays (see bottom of URL mentioned above). That should be a significant improvement, as the CPU doesn't wait on the GPU after every immediate call (i.e. glVertex2f, glColor3f, etc.)  It just sends the whole chunk at once (or, perhaps, even a pointer) to the GPU and is done with it.

Most of my experience has been tuning DirectX/360 code, so I don't know the full effect that using glDrawArrays (or maybe other, better options) will have until I try and test. Though you know your structures better, Toady, so you might be able to tinker with that faster.



First column is the particular function's individual contribution. Second column is the contribution of the function and all its children (i.e. everything it calls, everything they call, etc.)

glBegin is very quick (0.4%), but you see that including everything it calls, it alone amounts to (39.8%).  This is likely the CPU stalled waiting for the GPU to clear state, since that kind of thing needs to happen in immediate mode, iirc.

So you can see that gridrectst::render() is 71.3% of the overall time here. Adding up the gl*() functions (from glBegin down to glColor3f) amounts to 62.6% (if my head math is correct). That's a lot for sending geometry to the screen.

========

Also, keep in mind that on the Mac, there's also the timer/main loop issue you've mentioned when we got DF first time around. I wasn't all that familiar with Carbon, which is why I put in a timer. You could try having the timer fire more frequently...

[Mel_Vixen]

We need defintly an little Programmer/technical subforum when i see that discussion above.

[dreiche2]

So mattmoss, will you look into rearranging things into arrays? Otherwise I might have a go, too, but let's not do the same work twice.

[mattmoss]

So mattmoss, will you look into rearranging things into arrays? Otherwise I might have a go, too, but let's not do the same work twice.

Ya, I'm going to look into it tonight; I'm going to hook up a timing profiler as well to get some actual numbers. Might try VBOs as well, seem like they could be the best option...

[Toady One]

The person who wrote the Mac Accelerator is also looking into this and we've communicated via email but he isn't on this thread yet as far as I can see reading it.  It would probably be beneficial if a lot of people aren't all doing the same thing independently.  I'll send him a message.

[Baughn]

Said person would be me. Right, status update:

In the accelerator, and as standalone code, I've tried using quite a few different ways of rendering. To summarize, from memory (the number may be off):

- Using immediate-mode calls, but minimizing redundancy (no calling glBegin per tile) I get about twice the speed of DF
- Replacing quads with triangle strips yields another 20% or so
- Display lists are useless, since the texture needs to be set /somehow/ on a per-tile, per-frame basis
- Using a static_draw VBO to feed a triangle strip, and a dynamic_draw one for the textures, produces an enormous jump in speed - close to zero cpu use at 60fps, thousands of frames per second
- Switching to using *two* dynamic_draw setups for the textures moves cpu use even closer to zero, but doesn't affect framerate on my laptop. Like anyone would care at this point.

However, the last setup doesn't handle background colors. I could emulate that in a variety of ways, but instead I decided to use a pixel shader, and upload the tile control data (foreground color, background color, texture pointer) as a texture once per frame instead. Alternating PBOs, that slightly drops cpu use, drops max framerate to four hundred and something (at 40% cpu use. Fill-rate limited. Heh.), and is generally amusing.

It also doesn't work on GPUs without pixel shaders, but to be honest, those were introduced so far back that very few opengl paths could be relied on to work on them - it'd pretty much have to be immediate mode to be sure.

You can find some standalone code that implements it on http://brage.info/~svein/dfview/ , by the way - it doesn't do the PBO alternation, mind.

So, right now I'm busy ripping out the guts of Battle Champs and replacing it with this - replacing the main loop with GLUT calls. It really doesn't suck as much as people think, and has the advantage of being preinstalled on macintoshes. The windows version can bundle it. Should be fine.

For the three people who are stuck on geforce 2s, I might add an SDL/2D path as well, or I might just leave that up to someone else. Probably the latter; I'll make sure to comment heavily.

[Baughn]

Well.

While replying to Toady's most recent email, I decided that SDL actually makes a lot of sense - I'm not, after all, writing haskell code this time around, so the standard objection of "But there's no good haskell binding!" is a bit.. silly.

So, rejoice. No GLUT.

[mattmoss]

- Using a static_draw VBO to feed a triangle strip, and a dynamic_draw one for the textures, produces an enormous jump in speed - close to zero cpu use at 60fps, thousands of frames per second

Yeah, this is what I expected to see. No more CPU waiting on every call!
So I guess I don't need to try that myself tonight...  I can play DF instead!  =)  Or this little battle champs thing...  lots of moving letters...  hmm, I have English class homework to do...

So, right now I'm busy ripping out the guts of Battle Champs and replacing it with this - replacing the main loop with GLUT calls. It really doesn't suck as much as people think, and has the advantage of being preinstalled on macintoshes. The windows version can bundle it. Should be fine.

As long as Toady is fine with that, cool.  It's probably what I should have done the first time around, rather than my ugly attempt to port KQ _and_ learn Carbon at the same time. Bad, bad bad...  there's a couple things about glut I'm not fond of, but it's simple, easy and works.

For the three people who are stuck on geforce 2s, I might add an SDL/2D path as well, or I might just leave that up to someone else. Probably the latter; I'll make sure to comment heavily.

SDL might or might not be cool to merge in, as per Toady's licensing...  but you'd have to ask him for details, and I don't recall what SDL's license is.

[mattmoss]

Well.

While replying to Toady's most recent email, I decided that SDL actually makes a lot of sense - I'm not, after all, writing haskell code this time around, so the standard objection of "But there's no good haskell binding!" is a bit.. silly.

So, rejoice. No GLUT.

Check with Toady... I would think GLUT might be more acceptable to him that SDL, but it all depends on the license. It'd be a bit of a waste to port to SDL and then not be able to use it.

[mattmoss]

BTW, Baughn....   AWESOME! Nice work...   

[dreiche2]

Nice to see things coming together. I've read a little bit about Glut and SDL in the last days, having used GLUT myself for the litte OpenGL I did something like six years ago. It seems that Glut is very simplistic and SDL much more powerful (but possibly "heavy" in whatever sense) as it can also do sound and stuff (and uh... threading, it seems  ).

From what I remember, the SDL license is something like you can use it for whatever you want, but it has some requirements about that you make it obvious that you use it or something... well, here:

http://www.libsdl.org/license-lgpl.php

[Toady One]

I discussed this most recently with Linux Port Person, and it is my current understanding from section 5 of the (quite obtuse) LGPL 2.1 that I don't have to comply with section 6 if I just use the DLL -- section 6 has all the change my title screen/include license stuff.  However, the link in the last post seems to contradict that, in that it insists on prominent notice without reference to link method, and the FAQ (http://www.libsdl.org/faq.php?action=listentries&category=8#6) makes it seem like nothing needs to be done.  If there's an SDL out under LGPL 3, I'm pretty sure that license won't work.

I don't have a problem with including the license (though that might be a bit confusing -- I'd have to make sure people don't think DF itself is under LGPL) or adding a notice to a txt (pleased to do so), but changing the copyright notice on my title screen to display not only the SDL copyright but also a link to LGPL seems a bit much.