Star Gauge 0.3.1a (Updated May 15th)

WIP games, tools & toy projects Archived Projects
#21

[quote]Anyway, I’ll stop guessing, and assuming.

You could add a debug-text showing stuff like:

“Rendering gui/own-ship took: xx.yyy ms”
“Rendering astroids took: xx.yyy ms”
“Rendering ships took: xx.yyy ms”
“Rendering background took: xx.yyy ms”
“Everything else took: xx.yyy ms”

Ofcourse use hires-timer. With that info we can narrow it down a bit.
[/quote]
I have a pretty good profiler, but things are a bit complicated in this engine because it’s completely multthreaded. Infact, I think that may be part of the reason ATi cards are having problems.

As I stated above, it’s a multithreaded game engine and it counts on the blocking to get other things done on the CPU. However…not very well with ATi cards it seems :frowning: Did you try running it without multithreading (checkbox on startup), maybe performance will be better. I am curious to know if it helps for ATi users.

#22

I just noticed D:\stargauge\ :o

excuse me? you’re lucky this is alpha/beta, so i won’t kick your ass :wink:

#23

Hehe…ya caught me! The webstart version of the game, isn’t going to be running the game at all, it’s going to be an installer.

Don’t worry, it’s just a couple of sound files :smiley:

#24

Single-threaded performance is worse: ~15fps when facing mars

OpenGL doesn’t care about your app being multi-threaded, as long as your calls are from 1 thread :slight_smile:

Multi-threading because of the (final) delay each frame, is quite nice, as the cpu is idling/waiting anyway

#25

[quote]Single-threaded performance is worse: ~15fps when facing mars
[/quote]
Ok, the multithreading is helping then…which is the goal of it :slight_smile:

That’s pretty much the goal of the design, the rendering happens in a single thread, but everything else is done in other threads. The engine is designed to take advantage of the waiting incurred during buffer swaps (or the next GL call that happens there after, depending on the scene and GL drivers). Benchmarks on the machines I have tested it on show a 15-20% improvement in FPS…but it sounds like improvement is much higher on your machine.

I have an ATi 9600 that I can stick into my box for testing. I’ll put it in over the weekend and see if I can profile the issue.

#26

Just the graphics, at least the background seems to twist somehow when i roll or at least when I start rolling - it’s hard to explain. Maybe it’s just the perspective settings you mentioned.

Bah… average Joes like me think it’s just a nice little effect 8)

#27

[quote]If you wouldn’t mind, could you try it again but don’t touch your speed or if you do…drop it back down to around 60-77 range and see if you find it eaiser.

If you are flying at 75 or so and the enemy is still impossible to keep on the screen, then I think the AI must have a timing issue.
[/quote]
I tried a lot of different speed settings, including the default, 200, and standing still. The enemies just flew by too fast to get a lock on them. If their speed is locked to the framerate then you should change it to be time-based.

[quote]Glad you like it and the music. I did the muisc myself and most of the sound fx. My first attempts at music and I think it came out pretty good. My wife thought I was crazy when I said I would teach myself that as well…and even more worried when I started spending money for it :slight_smile:
[/quote]
That’s fantastic. Programmer art that looks good!

#28

The engine FPS is supposed to be time capped at 62 FPS, with remaining CPU going to the renderer or awt threads. This thread controls the ship AI. The ships are sliced within that, none should ever update more then 62 times in a second.

What FPS is it showing for you (engine FPS)? Is your laptop using time stepping? If so, this could be the problem Cas says he has with all games.

#29

UPDATED:

I found a rather large bug that would explain the performance problems some were having, such as the ATi people. Actually, it was effecting everyone greatly, but those with really good video cards would have still found performance acceptable…now they’ll find it great :slight_smile:

The bug was causing static objects to be rendered with immediate mode calls, big performance hit, both for the card and the CPU.

With the fix in, I have doubled the number of visible asteroids and still have almost twice the FPS of before (worst case was 50 FPS on my box, now in the same spot with twice the roids, I get 90 FPS) :slight_smile:

Let me know if it helps those that were having FPS problems.

StarGauge 1.3.1a

Thanks for testing!

#30

Now I have a steady 40fps, which is nice, with so much more astroids, but still not like

[quote]Runs at 260+ FPS on my Quadro FX Go700 notebook
[/quote]
:slight_smile:

#31

[quote] Now I have a steady 40fps, which is nice, with so much more astroids, but still not like

Quote:
Runs at 260+ FPS on my Quadro FX Go700 notebook
[/quote]
Get a Quadro FX Go700 notebook then :slight_smile:

Still, glad it improved it for you. I’ll add a switch so you can turn down the viewing distance, which I doubled (thus twice the roids) for this version.

#32

Well I’m getting 25-30 fps quite steadily now. Big improvement considering that the number of asteroids was doubled.

#33

Glad to hear it. I am sure there is more I can do yet…