next »

[Liosan]

I have to say that this happenned to me too. About 400fps on my Athlon 64 X2 @ 2.9GHz + 2x2GB RAM + NV9600GT and about 800fps on my laptop with shitty Pentium Dual-core @ 2GHz + 3GB RAM + Intel HD...

Come on, that's less than 1ms difference between frame length... I think comparing FPS rates above 100 isn't really worthwhile. It doesn't necessarily mean that the slower computer will still be 2x slower when you actually start demanding something from the hardware...

Liosan

[rivon]

No no, this was counting frames in my "game" from the start (frames++ every frame) and at the end dividing them by the total time, so it is average fps. This wasn't based on the frametimes.

[Geti]

Wild guess - your laptop has an integrated graphics card, which uses shared RAM (not it's own, on the card). Maybe blitting to shared RAM is faster?

Liosan

Could be, but I'm using a software surface and memcpy based rendering -> its in main RAM on both. Using SDL_HWSURFACE does nothing (or at least, the ranges of jitter overlap largely) for my fps on either machine. :/

The rectangle blit now memcpys in a line of the correct colour index into the software surface as many times as it needs to make a square, which is about as optimised as I think I can make it at this stage.

I'll try to do some profiling and see where its eating time on the faster machine. It maxes out a whole core though, which is retarded. The same rendering algo in java ran at 20FPS on the weak laptop and 90-220fps (jitter) on the bigger computer.

This whole thing is leaving me like

[sigfarter]

In my experience, replacing the SDL rendering method with literally anything didn't change a thing. It is very suspicious.

Software rendering is very suspicious in general. I achieve hardware accelerated software styled rendering with my own engine because I know how convenient it can be, but it will be extremely clunky when it shouldn't be.

[Muz]

<input type="hidden" name="ctl00_PlaceHolderMain_g_ef5c7695_aade_4fcf_9064_d4abae536d0e_ctl00_trvSP_PopulateLog" id="ctl00_PlaceHolderMain_g_ef5c7695_aade_4fcf_9064_d4abae536d0e_ctl00_trvSP_PopulateLog" value="" />

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUBMA9kFgJmD2QWAgIBD2QWBAIBD2QWAgIHD2QWAgIDD2QWAgIDDxYCHhNQcmV2aW91c0NvbnRyb2xNb
(+16000 characters like this)
" />


God I hate reading ASP. Why does it have to be so damn fat, when the actual content people want to read is a Web 1.0 page of less than 2000 characters? It's like the opposite of compression.



Oh, and nested tables..
p in table in table in div in table in table in table in table in table in div in div in div in div in div in div in form in body

That's ok, I'll just take the ID of the one I need...
<div id="ctl00_PlaceHolderMain_g_8deb65f6_6164_46d0_b5cf_605c8b715c5c" webpart="true" __webpartid="{8deb65f6-6164-46d0-b5cf-605c8b715c5c}" __markuptype="vsattributemarkup">


FFFFFFFFFF....

[Geti]

Software rendering is very suspicious in general.

Mmn, I might look into how it's actually achieved on each of the main OSes and implement my own thing at some point.

Ken Silverman's Voxlap, for example, renders far more voxels per frame than I'm trying to and does so at breakneck speed, but afaik also uses a lot of ASM for some of the more maths-heavy parts of proper 3d rendering.

The flipside is, however, that I'm not doing proper 3d rendering or any expensive transformations. Literally taking out the pixel writing speeds everything up (both on the lappy that runs it playably anyway and on the bigger box).

As you said, very suspicious.

I might just write an OGL render for it and call it a day, next time I revisit it.

[sigfarter]

Honestly you should just do that, you will achieve better performance (if you don't implement it like a retard) and it will stop you from digging deep into the "how does SDL work" bottomless pit.

[Liosan]

You can get basic cross-platform hardware-accelerated 2D graphics for "free" if you replace SDL with SFML. It uses glBegin/glEnd, but still outperforms any form of software rendering.

Liosan

[rivon]

Or SDL2

[Nix]

Software rendering is very suspicious in general.

Mmn, I might look into how it's actually achieved on each of the main OSes and implement my own thing at some point.

Cairo is the biggest software rendering library

[d]

I just realized a problem I've been thinking about for a week requires finding an optimal intersection of problem and solution among a set of NP-complete problems.

[VortexCortex]

C and C++ are statically compiled languages.  They're strongly typed.  They make a point to be extremely fucking type savvy -- Except when they're just out to fuck with you, then they're just lazy elitist type snobs.

Consider the following:

Code:

int i = 4;
int d = -2;
unsigned int k = 10;

if ( k > i ) puts( "k is greater than i." );
else puts( "k is less than or equal to i." );

if ( k > d ) puts( "k is greater than d." );
else puts( "k is less than or equal to d." );

Which results in the following:

Code:

k is greater than i.
k is less than or equal to d.

That's right, 10 is less than or equal to -2.  Wait, what?

The type promotion rules specify that the signed value will be promoted to an unsigned value during the compare, so on a 32 bit machine -2 is treated as 4,294,967,294... which really is greater than 10.

No sane person would ever expect a statement like this to return true if a is positive number, and b is negative:

Code:

if ( a < b ) return true;
return false;

The problem is that the folks who created C were insane and lazy.

It's entirely possible to make the damn compare signs ACTUALLY WORK.
(Even my "toy" scripting language has working comparators.)

The compiler KNOWS the types are dissimilar, so it KNOWS it's about to fuck you over.  It could generate extra code to make their language constructs actually work, but: Lazy.

For instance, when comparing values of dissimilar signs they could generate an additional check to ensure the signed value (b) is non negative:

Code:

if ( a < b && b > 0 ) return true;
return false;

Down in the ASM, they'd only have to insert one CMP / JMP instruction pair after the first compare to make such comparisons work -- Any computed values would be in the registers anyhow.  If you've ever seen how much extra machine code is generated by doing pointer math, then you'd realize one compare & jump instruction pair is fucking trivial, even to the most "efficiency" focused fools.

In truth, this is an edge case in the language that the original implementers overlooked; Many years ago, after this trap bit a few folks enough times to complain and want it changed, the language designers just stuck their noses in the air and said: "Deal with it."

Even though I've known about this little pitfall since my "Hello World" days, I still chased down a bug for three hours that was staring me in the face the whole time -- Until I looked up the types of the vars, and facepalmed.

I just got so spoiled coding in other languages not created by assholes that I got used to having basic boolean logic that's actually logical.

Also, The Standard doesn't say what type a "char" will be -- It could be a signed or unsigned byte, it's arbitrarily up to the compiler...  How do you write correct comparison logic if you CAN'T know the fucking type?!  "Just don't compare chars" -- ugh, I'm getting sick of this "Deal with it." bullshit.

[Muz]

Huh, doesn't it at least give you a warning if you're comparing signed and unsigned stuff? I thought normally it gives errors.

Also, how do you even compare chars? If you're going to compare like if 'c' == 'd', there's functions to do that for you, IIRC. It shouldn't even matter if it's a signed or unsigned byte. It's a byte and the compiler should abstract those details out for you.

[Geti]

Huh, doesn't it at least give you a warning if you're comparing signed and unsigned stuff? I thought normally it gives errors.

Also, how do you even compare chars? If you're going to compare like if 'c' == 'd', there's functions to do that for you, IIRC.

char == byte -> signed 8bit int and unsigned 8bit int datatypes. Very useful for bandwidth optimisation.

In before "i don't use warnings" though Compiler should always give warnings about signed/unsigned comparison unless you're compiling with warning level 1 or 0.

[rivon]

GCC definitely throws warnings when comparing signed and unsigned ints.
When compiling, use the -Wall and -pedantic options to get all the warnings. Definitely worth it to correct all of them.