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

[Veroule]

Put together, these mean that a modern desktop CPU may (under ideal circumstances) be able to do one multiplication every cycle (the latency will be higher, but still only a few cycles) while needing several cycles to fetch data from memory.

That is part of why I always such a pisser about memory usage.  Another reason being that disk I/O is even worse.  Even on current systems with 3GB of RAM portions of the program data will start being tossed off into the swap file as early as 30MB used.
Anyway.  Baughn, if you commit the recent changes for graphics.cpp; then I will look at shifting some more things around in there.  There are still some strlen calls that need to be fixed, I should probably determine if Toady uses those methods.

It might also make sense to put all the different arrays for the screen buffers into a single class.  I did something like that when I was coding a full replacement for the graphicst class and had good speed results.  Among the things I would suggest as part of that change is to combine the texture number for graphic tiles and character number for font tiles into a single uint_16 or 32.  Fewer comparisons and pointers will make for better speed by freeing up more registers for important stuff.

[Bauglir]

-snip-

[A for Anonymous]

It is highly unlikely there would be a 64-bit version for windows, nor that there would be one for OS X so long as it starts up with a 32-bit kernel by default.

I'm not done reading the whole thread yet because it's huge, so please pardon if this has been pondered already but: The statistics from Valve's Steam (which are pretty viable for noticing hardware and OS trends) show a really REALLY high adoption rate of Windows 7 64-bit, with 30.59% of gamers using Steam already running an NT 6.x 64-bit OS, and there has to be some seriously high correlation between DF gamers and gamers that use Steam... So your statement isn't really quite as true (for Windows, that is).

[PencilinHand]

It is highly unlikely there would be a 64-bit version for windows, nor that there would be one for OS X so long as it starts up with a 32-bit kernel by default.

I'm not done reading the whole thread yet because it's huge, so please pardon if this has been pondered already but: The statistics from Valve's Steam (which are pretty viable for noticing hardware and OS trends) show a really REALLY high adoption rate of Windows 7 64-bit, with 30.59% of gamers using Steam already running an NT 6.x 64-bit OS, and there has to be some seriously high correlation between DF gamers and gamers that use Steam... So your statement isn't really quite as true (for Windows, that is).

Your assumption isn't strictly valid.  Most will probably agree that DF generally attracts a slightly different crowd than a more typical game experience, at least historically.

However, your conclusions isn't without merit.  The Window's 7 64-bit install base is growing at ~2.5 times the 32-bit install base, and I suspect the Linux community has an even higher 64-bit install base.  However, the more practical consideration of maintaining and troubleshooting the extra release versions is likely to be the biggest determining factor.  32-bit programs operate well(generally) in a 64-bit environment, while the reverse is not true.

It is, however, Toady's decision.  But if he did make a 64-bit Linux version, I would probably dual boot for it.  I have been meaning to get into Linux anyway.

[Baughn]

Veroule: The current development branch is "matrix", which has been seriously cleaned up relatively to the d19 code. I keep it up to date on github. It doesn't work with DF, being too changed, so instead use the stand-alone, misnamed "tetris" executable.

Still some bits missing - mouse support, shader mode mainly - but I'm fixing that now.

[Veroule]

Wow!  That is a lot of stuff moved around.  I am still reading through where you moved things, but it looks like you are finally sorting out some of the spaghetti and turning it into decent  OO organization.

[Baughn]

The old (d19) code causes a lot of opengl error conditions in various circumstances. It's supposed to be legal, but error handling is nowhere near as reliable as not having errors in the first place.

I realized the only way to fix the opengl problems was to not to cause them in the first place, so therefore this. It's going to cause a lot of extra work for toady. I'd have preferred to avoid it, but there was literally no choice. :/

[A for Anonymous]

However, your conclusions isn't without merit.  The Window's 7 64-bit install base is growing at ~2.5 times the 32-bit install base, and I suspect the Linux community has an even higher 64-bit install base.  However, the more practical consideration of maintaining and troubleshooting the extra release versions is likely to be the biggest determining factor.  32-bit programs operate well(generally) in a 64-bit environment, while the reverse is not true.

What it boils down to, in the (possibly very) long run, is that the 32-bit install base will, at some point in the future, be so marginally small that supporting it becomes pointless.

However, at that point in time, starting a 64-bit build would take even longer to do than it would now, as the code base will have grown enormously and the probability for there to be issue with porting will be much higher.

It is, however, Toady's decision.  But if he did make a 64-bit Linux version, I would probably dual boot for it.  I have been meaning to get into Linux anyway.

That it is Toady's decision is without question, but from what I can tell Baughn and the rest of the d# development team have a (somewhat) bigger influence on decisions Toady makes in that regard, thus I was merely pointing out that Baughn might want to rethink his position on NT 6.x 64-bit builds. (NT 5.3 [XP 64-bit] builds being rather pointless at this point, as people are rapidly migrating away from it due to the numerous issues with it.)

[xoen]

Although that build(d19) works very fast, save from d16 seems to work fine, BUT i CANNOT link floodgate..:E

I mean i can select floodgate linking option, but cursor is lost, also i cannot choose that specific, new floodgate manually - path is ok..

Scrolling through floodgates is weird, screen jumps into places where no floodgates are present.....

upd: but function works(i just cannot see cursor in proper place - it is visible while mechanisms are choosed).

winxp,
[PRINT_MODE:STANDARD]
[SINGLE_BUFFER:NO]

[Baughn]

Renderer threading is implemented, and (seems to) be working. In one (admittedly extreme) case, it doubled my framerates in 2D mode; it has less effect on the opengl modes.

The way this is setup, it might even be useful on single-core processors. I'll be looking forward to reports on d20, or.. df2010-2, perhaps.

(There's almost certain to be race conditions in there, though. I'm not going to claim I've thought of everything, not just yet. *shudder*)

[Veroule]

I have to really study what you did with the threading.  My first perusal gave me the feeling that something was not quite right, but I can't quite put my finger on it.

[Veroule]

Ok, found one thing that were causing me a bad feeling.

The creation of the  thread in main() of enabler.cpp.  This is done before the initilisation of various required structures in enablerst::loop.  You may have sporadic early crashes as a result.  Fix this by moving the if...SDL_CreateThread directly after the if's for allocating the appropiate render.

[Baughn]

That shouldn't be a problem.

The thread is created early, yes, but it then hits run_frame and blocks until SemPost is called from do_frame.

[jfs]

I'll see if I can make the matrix branch build on Win32 with MSVC, I'll also see how well it works on 64 bit Windows (6.0).

[Baughn]

One file is missing (find_file_win32.cpp or so), so it won't. I'll get that from toady later today.