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

[Andir]

Everything seems to check out fine.  Hopefully Toady will have time to push out a D20 so you can get a larger group of testers before it goes into the final merge.

But yeah, it's probably overkill to even think about this. It's mostly just that I'm a perfectionist, and I'm totally out of low-hanging or even high-hanging fruit, so I'm looking for rare fruit growing at the peak of mount olympus.

Your mission should you truly seek the Golden Apple of Calixti: Write a new options screen allowing users to control all graphical items on the fly.  They should be able to load different tile sets, adjust the fps caps and display thereof, change between drawing modes, turn on graphical tile usage, adjust the PP count, and change the colors.

If you make it able to save out to the init.txt while still preserving the comments then you will also be given the Sacred Cherry of Cthullu.

Speaking of perfection...

Code: [Select]

for (int x2=0; x2 < dimx; x2++) {
    for (int y2=0; y2 < dimy; y2++, ++off) {
I see someone is using prefix incrementation and someone is still using postfix increments.  I grabbed this bit out of the enabler.cpp in the matrix branch but I didn't really dig into much more than that to see if this was called every frame.  If you do have loops in the frame it would be more efficient to use prefix operators where order of incrementation doesn't matter (like for loops, single line incrementation...)  I know this was the case in C, and I assume C++, but prefix operators do not require the allocation of a temporary return variable to be used by the calling function before incrementation.  A prefix operation simply increments the value in memory and returns that value.  It's a few less lines of assembly, a few less memory allocations, and a few more ticks of processing performance.

I don't know if your compiler optimizes this, nor have I dug into the assembly of an application to test this, but I read about it a few years back and it totally made sense.  I've pretty much integrated it into my regular practice.

(edit: Line 242: frames--; // another example where you would be allocating memory for both the original value and the decremented value...  --frames; // should be more efficient)

[Exponent]

I don't know if your compiler optimizes this, nor have I dug into the assembly of an application to test this, but I read about it a few years back and it totally made sense.  I've pretty much integrated it into my regular practice.

I agree in general, but I think that it is dead easy for a compiler to optimize post-increment for a trivial type when the r-value isn't actually being used.  Non-trivial iterators (such as a list or map iterator) are probably different, but I wouldn't worry about things like ints, pointers, or vector iterators.

Then again, we have just recently seen how dumb compilers can seem to be.  (Or how subtly wise they can be in avoiding sneaky errors that naïve optimizations might produce.)

Though I do agree about using prefix increment in all cases where a postfix is not specifically required, as a matter of style.  That way you know that even a stupid compiler (or debug mode?) will be more efficient.

[Petr Ga]

just for your curiosity: prefix vs postfix
Timings: Prefix 5.19s user time, Postfix 4.63s user time.
But this was latter in discussion disputed

I don't know if your compiler optimizes this, nor have I dug into the assembly of an application to test this, but I read about it a few years back and it totally made sense.  I've pretty much integrated it into my regular practice.

I agree in general, but I think that it is dead easy for a compiler to optimize post-increment for a trivial type when the r-value isn't actually being used.  Non-trivial iterators (such as a list or map iterator) are probably different, but I wouldn't worry about things like ints, pointers, or vector iterators.

Then again, we have just recently seen how dumb compilers can seem to be.  (Or how subtly wise they can be in avoiding sneaky errors that naïve optimizations might produce.)

Though I do agree about using prefix increment in all cases where a postfix is not specifically required, as a matter of style.  That way you know that even a stupid compiler (or debug mode?) will be more efficient.

[doomcup]

Use PRINT_MODE:2D.

Ah, thank you. Yes, it seems to be working now.

Another thing to report, sound doesn't seem to be working for me, probably because I'm using OSS4 instead of ALSA.

[Andir]

just for your curiosity: prefix vs postfix
Timings: Prefix 5.19s user time, Postfix 4.63s user time.
But this was latter in discussion disputed

All bets are off if all the bits and pieces are declared inline. If iterator:: operator++() is inline, and the iterator copy constructor is inline (both are likely to be the case), then the compiler gets an unfettered view of the actual semantics of the operation. It is able to see that the prior value of the iterator is unused after the post-increment, and it is able to see that the iterator's copy constructor has no side-effects. Therefore the compiler eliminate the construction and return of the prior value of the iterator.

That's kind of what I figure and it's the key point here.  I assume (/am pretty sure) that the operators are inlined so it would boil down to how the compiler handles it.

[Veroule]

RE: The prefix/postfix debate.  It doesn't matter in this case.  Those are all simple int variables and when compiled it produces an INC instruction either way.  The only difference is where the compiler puts the INC.

A few other polish tweaks:
In renderer::gps_allocate, all the memset's can be eliminated if you set full_display_count.
I am pretty sure that even with PARTIAL:n a full_display_count of 1 is adequate to arrange the graphics buffers correctly.  This means that all instances of full-- can be full=0 and all full++ can be full=1.  If this is done then the full=5 during initialisation steps should also be changed.
I am guessing you already do this, but I didn't check.  When using STANDARD do not clear the full_display_count.

I think the single buffer option can be completely removed.  It produces flickering even on the oldest test system I have available and I don't think anyone has reported it as working or being an improvement.

Likely the same with VSYNC, I don't think there were any reports of it making things better.

[Baughn]

Given that the data types in question are plain ints, it's a non-issue. The optimizer reduces pre and postfix to the same operation in this case, assuming you don't use the expression value.

[Baughn]

There are a few people for which single-buffer works better on than off. Given that the cost of leaving it in is essentially zero, I see no reason to remove it.

EDIT: Veroule: Right, I think that's pretty much it. Everything's working, as far as I can see, including things that never used to work (like resizing the window while a movie is playing).

I've merged the matrix branch into master and deleted matrix, so you'll have to update your pointers. Anyway, care to make sure I haven't missed anything?

[Rafal99]

Yeah the fastest modes for me which are PARTIAL_PRINT and ACCUM_BUFFER only worked with SINGLE_BUFFER=YES.

[Veroule]

Yeah the fix for the guy that reported graphic tiles not being erased properly.

In graphics.cpp, graphicst::erasescreen() add the line.
if (screentexpos) memset(screentexpos, 0, dimx*dimy*sizeof(long));

In grahpics.h, graphicst::addchar
Move the line
screentexpos[screenx*dimy + screeny]=0;
above the other sets.  Change the "screenx*dimy*4 + screeny*4 + 0" to "(screenx*dimy + screeny)*4 + 0" so the compile can optomize the common expression.

Same treatment for the second version of that function which doesn't currently clear the use of graphical tile.

[Petr Ga]

bug report:

"Export local image" is broken. It contains multiple instances of "export local image window"

[Rafal99]

bug report:

"Export local image" is broken. It contains multiple instances of "export local image window"

Already known. It is even posted in the first page in "Known bugs" section. Needs Toady to make fix in his part of the code.


Can someone add the bug with lever linking and screen jumping to wrong places to the list? There is "Bridge linking is broken" bug there, but I think it was related to some messed keys, so it is another bug.

[Veroule]

Another bit of polishing:

Curses printing and use of graphical tiles are mutually exclusive.  At the end of init.txt loading you should add a check for both being set, warn the user and disable the graphical tiles.

[shadow_slicer]

Another bit of polishing:

Curses printing and use of graphical tiles are mutually exclusive.  At the end of init.txt loading you should add a check for both being set, warn the user and disable the graphical tiles.

Speaking of which, are there plans to allow a pseudo-graphics mode for curses -- such as using configurable unicode characters as graphics?

[Baughn]

Not, I think, a very useful concept in practice. Fonts are too unpredictable.

You should just use a graphical mode. The threading in the current version actually makes those faster than curses, so.. yeah.

Also, test added.