Print

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

Faster, no (unknown) problems

Faster, problematic

Same speed, no (unknown) problems

Same speed, problematic

Slower, no other (unknown) problems

Slower, problematic

Doesn't work at all

[Wurm]

The Game crashes during saving when using PARTIAL:0, ACCUM_BUFFER, and FRAME_BUFFER.

Hardware: AMD Athlon X2 2.6Ghz, 1GB Radeon HD 5750 - Catalyst v.10.1 - OpenGL v.6.14.10.9252, Windows XP SP3 32bit, 2GB ram.

Other than that, it works fine with STANDARD. Although the FPS Counter tends to get in the way of things.

[dorf]

WinXP SP3, Radeon 9600XT, P4 single-core 2.6GHz.

- (region?) title text weirdness during worldgen, but is fine when it's paused. And weird again, when continued. And fine again at the end of gen.
http://i49.tinypic.com/fm86sx.png
http://i50.tinypic.com/28vsoc9.png
http://i48.tinypic.com/4qnc7a.png
NOTE: This happened on an NVIDIA card, as well.

- loaded reinhammers save (same results as in d17 and d18):
40d: 11 FPS; [PARTIAL_PRINT:YES:0]
40d19: 7(7)/7 FPS; works fine; [PRINT_MODE:STANDARD]
40d19: 7(7)/7 FPS, works fine; [PRINT_MODE:2D]
40d19: 7(7)/7 FPS, works fine; [PRINT_MODE:2DHW]
40d19: 7(7)/7 FPS, works fine; [PRINT_MODE:2DASYNC]
40d19: 7(7)/7 FPS, works fine; [PRINT_MODE:PARTIAL:0]
40d19: 7(7)/7 FPS, a lot of artifacts; [PRINT_MODE:ACCUM_BUFFER]
40d19: 7(7)/7 FPS, a lot of artifacts; [PRINT_MODE:FRAME_BUFFER]
40d19: - FPS, unplayable (worked in 40d17); [PRINT_MODE:VBO]

some sshots from the intro with the VBO mode:
http://i45.tinypic.com/dnk2g5.png
http://i50.tinypic.com/1445g9f.png
http://i50.tinypic.com/11j7k7n.png

Have the crashes on various screens (farm plot, and I think there was another) been fixed?  If not, they should probably be listed among the known bugs.

I built a farm plot outside, did the "q>Farm plot>c" and it didn't crash (in 40d19 or 40d18).
But I wasn't the one that reported the problem, so we should wait for him to drop by.

The Game crashes during saving when using PARTIAL:0, ACCUM_BUFFER, and FRAME_BUFFER.

Confirmed. It happens somewhere in the Cleaning game objects stage for me.

[Vince]

System: Intel Core2Duo 2,1Ghz, GeForce 8800GTS 195.62 Vista 32bit

The bad: [PRINT_MODE:SHADER] crashes, Vista says in Module nvoglv32.dll
The good: [PRINT_MODE:VBO] now finally works for me! 171 dwarves, 25 fps in the main corridor, that's nice!

[Qiu]

PowerPC G5, MacOSX 10.4.11

works perfectly, very slightly faster than 40d10 (the fastest version for me so far)
I have no problem saving the game (didn't test that a lot though)
The FPS counter can indeed mask some game text.

One minor thing, when clicking on "generate new world", you have to press F9 to continue to world gen (it was F8 previously) it can cause problems for Mac users in windowed mode as it is the default key for "exposé : show all windows".
Thank you for all your work. 

It looks like you've finally hit the mark - this one's just as fast as 40d, if not faster in a few places.

[Malicus]

you have to press F9 to continue to world gen (it was F8 previously)

It's always been F9 for me.  Odd.  (Maybe the F8 was an OSX thing that got missed this time?)


As far as my experiences...  I played a while and it seems to be doing fine (the random slowdowns are gone now due to ARB_SYNC, I think), though I can't really stand actually trying to DO anything without Dwarf Therapist, so I think I'll wait a bit before I actually test it by doing more stuff on my fort with d19.

[Baughn]

- loaded reinhammers save (same results as in d17 and d18):
40d: 11 FPS; [PARTIAL_PRINT:YES:0]
40d19: 7(7)/7 FPS; works fine; [PRINT_MODE:STANDARD]
40d19: 7(7)/7 FPS, works fine; [PRINT_MODE:2D]
40d19: 7(7)/7 FPS, works fine; [PRINT_MODE:2DHW]
40d19: 7(7)/7 FPS, works fine; [PRINT_MODE:2DASYNC]
40d19: 7(7)/7 FPS, works fine; [PRINT_MODE:PARTIAL:0]
40d19: 7(7)/7 FPS, a lot of artifacts; [PRINT_MODE:ACCUM_BUFFER]
40d19: 7(7)/7 FPS, a lot of artifacts; [PRINT_MODE:FRAME_BUFFER]
40d19: - FPS, unplayable (worked in 40d17); [PRINT_MODE:VBO]

At this point I'm goin to chalk that up to optimization differences in DF itself. It pretty much can't be due to the graphics code, not with all the modes giving the same FPS.

some sshots from the intro with the VBO mode:
http://i45.tinypic.com/dnk2g5.png
http://i50.tinypic.com/1445g9f.png
http://i50.tinypic.com/11j7k7n.png

..wow. Okay. I think you probably shouldn't use VBO mode.

[Baughn]

One minor thing, when clicking on "generate new world", you have to press F9 to continue to world gen (it was F8 previously) it can cause problems for Mac users in windowed mode as it is the default key for "exposé : show all windows".

You can change that keybinding in the key-binding screen.. somewhere.

Try that, you can give me feedback on the new layout too.

[Qiu]

You can change that keybinding in the key-binding screen.. somewhere.

Try that, you can give me feedback on the new layout too.

Ah, of course, why didn't i think of this ; it works, and the new layout is a lot clearer. 

[The-Moon]

Urm :|

Your joking right?

Honestly if there are those kinds of errors, i think we should find someone a little more competent to code the sdl/opengl part. Why the hell your even using opengl i dont know. Only need SDL. No reason to have opengl honestly.

Not that we dont appreciate your work, but with bugs like that, you clearly dont have much of a understand of sdl/opengl to be working on this. Im sure theres plenty more qualified people to be working on a better gfx engine.

Be nice to see someone else step up who has done this before

[Urist McDepravity]

Honestly if there are those kinds of errors, i think we should find someone a little more competent to code the sdl/opengl part. Why the hell your even using opengl i dont know. Only need SDL. No reason to have opengl honestly.

You know, in FOSS world you either do it yourself or STFU.

[The-Moon]

Honestly if there are those kinds of errors, i think we should find someone a little more competent to code the sdl/opengl part. Why the hell your even using opengl i dont know. Only need SDL. No reason to have opengl honestly.

You know, in FOSS world you either do it yourself or STFU.

If this guy knew what he was doing there would be no bugs right now

And i could easly setup SDL code, OpenGL no since df is never going to be 3d without a major rewrite. So theres no point in coding in opengl, sdl will work fine for graphics.

So yes i could easly teach toady how to use sdl, its not that hard to do

[Baughn]

Urm :|

Your joking right?

Honestly if there are those kinds of errors, i think we should find someone a little more competent to code the sdl/opengl part. Why the hell your even using opengl i dont know. Only need SDL. No reason to have opengl honestly.

Not that we dont appreciate your work, but with bugs like that, you clearly dont have much of a understand of sdl/opengl to be working on this. Im sure theres plenty more qualified people to be working on a better gfx engine.

Be nice to see someone else step up who has done this before

You're welcome to try. Go right ahead, the code is public.

You may find that it's harder than you think to write robust code when a lot of the code is locked in and unchangeable. Or to make zooming fast if not using opengl. Or working around the myriad bugs in opengl implementations without having access to the hardware in question yourself.

But by all means, try. I'd be *overjoyed* if someone competent would help.

[The-Moon]

Urm :|

Your joking right?

Honestly if there are those kinds of errors, i think we should find someone a little more competent to code the sdl/opengl part. Why the hell your even using opengl i dont know. Only need SDL. No reason to have opengl honestly.

Not that we dont appreciate your work, but with bugs like that, you clearly dont have much of a understand of sdl/opengl to be working on this. Im sure theres plenty more qualified people to be working on a better gfx engine.

Be nice to see someone else step up who has done this before

You're welcome to try. Go right ahead, the code is public.

You may find that it's harder than you think to write robust code when a lot of the code is locked in and unchangeable. Or to make zooming fast if not using opengl. Or working around the myriad bugs in opengl implementations without having access to the hardware in question yourself.

But by all means, try. I'd be *overjoyed* if someone competent would help.

Edited for typos....

All toady needs to do is learn how to draw stuff with sdl, learn input from the keyboard mouse, and setup music and hes done, nothing more needs be done. Its not drawing that much complex stuff?

I fail to see the problem.... :|

[Dabi]

Well...I don't see why he's having a go at Baughn when the codes public??? it's not like Baugn is getting paid...(?? Correct if I'm wrong)
The general tone of what you said previously sounded insulting.
Codes public so either you fix it yourself or someone else does or just ignore it since it isn't affecting you.

[Totaku]

Ok time to explain the results of my testing for this version.

Once again used the same fortress, plus a new fortress to test saving...

As before, I use a Mac OS X Tiger version 10.4.11
2 GHz Intel Core 2 Duo Processor
1GB 667MHz DDR2 SDRAM Memory

I've tested both the PC and Mac version.

To play the PC version I used Crossover Emulator V.8.0.

For the test I set Prority on HIGH and Texture to NEAREST

Here's the results of the frame rates...

Standard: 60-70 (19) / 50-80
Partial : 65- 79 (19) / 55-85 (results were similar from 0-2)
Accum_Buffer: 75-80 (19-20) / 50-85
Frame Buffer: game freezes, force to close emulator, unable to collect data
VBO: 69-75 (19) 50-85
Shader: Doesn’t work, probably due to not having a DX10 card   

compared to last time the frame rate has jumped up quite a bit, at least based on what the FPS says...

Sadly Frame buffer still doesn't work, but at least it doesn't kill my computer so I have to reset it.

Other things I like to note are is that saving doesn't seem to work when you use PARTIAL and ACCUM_BUFFER settings. They end up causing the game to freeze at "Cleaning game objects...". And this is only within the PC version.

Also it's important to note that the title music that usually plays at the title screen doesn't play. In fact, it only plays when you select a option like Create a new world. And also when you play a game and save it. The music that plays during the game continues to play all at the title screen. Thus is very awkward.

Also to point out something else...

It seems now titleset images that appear in the game seem to stay around as you go through other menus. They then to disappear only when you resize or text just happen to run into the tileset.

Here's a good example I have using my Suika Fortress mod.

Spoiler (click to show/hide)

Kinda strange if you ask me...

Now I go on to play the mac version using the terminal.

Surprisingly it seems to have become a tiny bit faster compared to d18 in some parts

Standard: 39-41 (20)/ 35-50
Partial: 47-50 (20)/ 38-53
Acuum_buffer: 45-48 (19) /32-55
Frame_buffer: Crahsed computer, forced to restart
VBO:40-48(19) / 38-50
Text: Too difficult to determine…

Still leaves some room to desire, but it's a bit of an improvment. Still it runs slower, but I'll cover some more on that later on.

As for text, I'm interested in the idea your pulling off here mainly because I recall Stone Soup Crawl using a very simalar concept for the mac text version. Though I'll have to say, as of right now, it's quite a mess. It's hard to tell what's really happening...

Spoiler (click to show/hide)

I can distinguish some things, but the majority leaves me saying "wha?"

Now on to the performance on Mac issue...

Baughn, I recall you asked me to look into valgrind to get some results. Course I think I should point out, that my knowledge on Terminal is rather......limited. Plus I'm unsure how valgrind exactly works. So...is there like a "Valgrind for dummies guide"  out there for the less programmer savvy?

Other than that, this covers my report.