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

[jfs]

For the tetris/matrix test application, having all do-nothing functions for find_files_*.cpp seems to work fine.
The main issue I had building it was that music_and_sound_fmodex.cpp expects a function enablerst::get_timer() which doesn't exist, so I had to add that. I haven't had time to test different configurations yet.

[Veroule]

That lockup is clearly related to a thread timing issue.  It went away when I changed line 94 of tetris.ccp from "SDL_DELAY(2);" to "for (int i=100000;i;i--) ;".  When you want to waste time you have to get old school and use a dumb loop.  Brings back fond memories of adjusting loops to the exact number required for the timing I wanted.

[Baughn]

Ah, but what if I don't want the lockup to go away?

Anyhow, well searched. This one should be reasonably simple to solve at least.

EDIT: Except I can't make it lock up. Oops.
Do you by any chance have a single-core?
Also, are you sure it's a SemWait lockup?

[Veroule]

I am absolutely positive it is the SemWait in quiesce that it is locking on.  The value in outstanding_frames was 0x49400 when it went into the decrementing loop, and it passed the SemWait between 60 and 70 times before locking there.

Yes single core machine for testing this.

[Baughn]

Which would imply that it's out of touch with the semaphores.. you could use SDL_SemValue to figure out what that value actually is.

outstanding_frames is meant to be the sum of the values in the two semaphores. Those values are touched in only two ways - in async_loop, where one is decremented and the other then always eventually incremented, and in those three functions in enabler.h. For the life of me, I can't see how they can get out of sync.

The "> fps" bit in trigger_async_loop is uselessly costly for high fps values, though. I've made it "> 100", which definitely shouldn't fix the problem but does avoid having to decrement it from 40,000 to 0 when any input arrives.

[Veroule]

I pretty much restructured the whole usage of semaphores and the way the basic timer works.  Everything seems to work fine on my single core test system.  It is still a little sloppy, but it is faster.

The biggest jump was on the max speed (no slowdown in Matrix:logic) and ASYNC:YES.  That got a 50% increase.  ASYNC:NO got a modest 20% hike here.  There is still a significant speed difference between the 2 of them and the only way I could close that gap further is to replace all the semaphore stuff with my own ones.  Sadly they are licensed to a commercial app.

I will send you the changed files.

[Veroule]

Files sent to your email.

[xoen]

Weird event made me leaving that version off my interest.
I'd be glad to hear it may be d16 save issue.

Well - i played for few hours, and suddenly dwarves started to carry junk into bins placed AT FURNITURE STORE.
I deleted that assigned space, made another.
None of these items were carried there, but all right, small guys might've been busy.
But, suddenly, i saw weirdest thing ever.
Walls and floors of CERTAIN area at z-3 became visually...dwarven corpses and coffins.
"k" still named these as walls and floors, but damn, it looked as coffins and dwarven bodies.
I quitted and reloaded, same situation, changing display engine did not help.
Unfortunately, being drunk i hastely deleted save, build, and gone sleep..
I was stupid i did not left these for further testing.
No screenshot, too.;/
Shame i do not remember, if i used DT with that build, i think i did not, almost sure of it.
It could explain that behaviour(my personal suspicion), f'ed up mem regiters, whatever.

Now i am afraid to test that build again, i do not want to see sth like that after x hours of playing..

Sigh.

(sorry for my engrish..)

[Baughn]

d19 appears to have a bug where blank spaces will sometimes show graphics. This is due to the blanking process only clearing the non-graphical slot, and me not checking properly.

It shouldn't happen with graphics off, mind. Did you have it on or off?

[Footkerchief]

That's the idea, but it's possible (with "Full graphics support" at #6 on Eternal Suggestion Voting) that these improvements will become obsolete in the near future.

Then what are they/we/Baughn actually working on right now? I thought they were messing with the "core" graphical elements of the code. Are they not? Have I totally gotten it backwards? Cuz if they are, then even if Toady adds all sorts of flair, he'll be building on these optimizations. He'll /have/ to be.

Baughn is working on tile rendering, the most "external" part of DF's graphics.  The first step for "Full graphics support" will probably be decoupling text from tiles and allowing flexible tiles for items/terrain/maps -- Baughn's optimizations will still be useful there.  However, Toady has talked about supporting other stuff later on, like variable-width fonts and isometric rendering, which would break many of the assumptions that inform Baughn's work. 

[xoen]

d19 appears to have a bug where blank spaces will sometimes show graphics. This is due to the blanking process only clearing the non-graphical slot, and me not checking properly.

It shouldn't happen with graphics off, mind. Did you have it on or off?

..but these were not blank spaces... i know what you are talking about, i had every single being alive visible like in-game in "z" or other screens, just like refresh wasn't working.
And yes, i am using gfx(ascii is ok for ADOM, NOT for DF, imho, too much confusion) - mayday + numerous mods with its gfxes.

[Baughn]

What you think isn't blank space may not, in fact, not be blank space. Especially if you have not refrained from installing the mayday pack.

I really shouldn't forget to not leave the bug in now.

[xoen]

What you think isn't blank space may not, in fact, not be blank space. Especially if you have not refrained from installing the mayday pack.

I really shouldn't forget to not leave the bug in now.

ok.

[Baughn]

Veroule: Your patch has some good ideas, but.. then again, it has some bad ones too. The worst offender is using the SDL event queue.

That queue does not guarantee that, if you push an event, it'll come back out the other side. Especially if you push a lot of events on it, you risk the loss of some, like for example keyboard input - losing a key release event is just bad.

No, I'll use some of the concepts, but not that implementation.

[Veroule]

Yeah pretty much what I expected.

It is sad about the SDL event queue, because using that for the timer system is a smooth jump in speed for both modes.  The silliest part of that is that the size of SDL's queue can be controlled during compilation.  The default setting in the library is 100 events held.  It is almost worth it to up that number to something reasonable, for example Windows message queue has a limit of 10,000; then include that library with the distribution.  I have seen some threading implementations hit the Windows limit and then crash oddly, so I do know the risks.

I will be looking forward to what you put together.  Your skill and attention to detail is always impressive.