Helbreath Performance

[Jaap]

No, don't scale the sprites. This way, more room for everything! 800x600 hb with normal sprites is actually pretty good.

[MOG Hackintosh]

That will increase the range of sight by quite a bit, making it harder to escape certain unwelcome situations. HB does not impose a limit on reach of spells or arrows, only on the range of monster attacks.

[MOG Hackintosh]

By the way, 640 by 480 hb looks like crap in LCD monitors.

[Slayer]

By the way, 640 by 480 hb looks like crap in LCD monitors.

no shit..

[MOG Hackintosh]

I only found that out recently. Other games such as DAoC look fine on my 20" LCD...but not hb.

[Slayer]

I only found that out recently. Other games such as DAoC look fine on my 20" LCD...but not hb.

Yea, I know , 19" only here =[
Get COD2 demo if you like shooters

[snoopy81]

On my shinning new 19" LCD, HB looks fine, even better than on my previous VisionMasterPro 19" .
Reason is quite simple : alike many 17" or 19" LCDs, resolution 1280x 1024. and 640x480 is nearlly half. If monitor is smart enought to put 2 little black bands top & bottom, it's perfect.

[MOG Hackintosh]

Daniel, wake up! Jaap! Anything new on this?

[Slayer]

On my shinning new 19" LCD, HB looks fine, even better than on my previous VisionMasterPro 19" .
Reason is quite simple : alike many 17" or 19" LCDs, resolution 1280x 1024. and 640x480 is nearlly half. If monitor is smart enought to put 2 little black bands top & bottom, it's perfect.

That would give a streched view, as there are no strokes on the sides, causing the players to look fat (atleast, on my friends 'widescreen' laptop it's like that).

[MOG Hackintosh]

I still want to see if Jaap will continue his dissertation about FPS. Did he just give up?

[Slayer]

I still want to see if Jaap will continue his dissertation about FPS. Did he just give up?

lol, I will ask jameson =/

[MOG Hackintosh]

Well here is why I am curious. I think most of what he said is irrelevant or untrue, except for that bit about FPS. Since I want him to elaborate, I guess I'll explain...

> #1 - Unnecessairy POST-function checks

While you're right that these should be assertions, the impact on performance is negligible. It'll take all of 2 cycles to do the comparison and branch (the branch will be predicted correctly by the CPU unless the check fails, which you'd hope was never or at worst rare).

> #2 - Allocation before check

Depends. If they're doing memory allocations then yes, but if the variables are all on the stack then moving them will make 0 difference to performance. Allocation a variable on the stack is nothing more than an addition to the stack pointer, so technically putting them all together would be slightly faster (a single addition to allocation them all at once instead of in several different locations)

> #3 - Numerous of unnecessairy switch/if statements

The dereference of the function pointer you suggested to use instead would cost just as much as the jump table the compiler would generate for this. Besides, if you want object-oriented you'd use virtual functions, not function pointers....

> No MMX alpha blending blitter

While they could have benefitted from this, I myself will not (Since I am using OpenGL I let the graphics card do this, not software)...

> Also, alot of unnecessairy checks are done during the drawing of the sprites.

Again, the performace impact is negligible. In fact, the suggestion you make would actually cost more than a simple comparison because of the need to dereference the function pointer

> This removes alot of checks and wasted cpu cycles, so speed improvements should be noticed!

Afraid not. You could easily spend weeks implementing these changes only to discover that you gained a whooping 0.1 frames/second. What you're doing is called micro-optimising, which is totally useless unless you're in a loop that gets repeated many hundreds of thousands of times per second (the software blitter you mentioned above would be a suitable candidate for these sort of optimisations...if we didn't have hardware to do it for us).

What you want to look at instead is the high-level algorithms used. And then post your findings, please....I'm really curious, since I don't have the time myself, and it's a lot of work and all...


MOG

[Slayer]

Well here is why I am curious. I think most of what he said is irrelevant or untrue, except for that bit about FPS. Since I want him to elaborate, I guess I'll explain...

> #1 - Unnecessairy POST-function checks

While you're right that these should be assertions, the impact on performance is negligible. It'll take all of 2 cycles to do the comparison and branch (the branch will be predicted correctly by the CPU unless the check fails, which you'd hope was never or at worst rare).

> #2 - Allocation before check

Depends. If they're doing memory allocations then yes, but if the variables are all on the stack then moving them will make 0 difference to performance. Allocation a variable on the stack is nothing more than an addition to the stack pointer, so technically putting them all together would be slightly faster (a single addition to allocation them all at once instead of in several different locations)

> #3 - Numerous of unnecessairy switch/if statements

The dereference of the function pointer you suggested to use instead would cost just as much as the jump table the compiler would generate for this. Besides, if you want object-oriented you'd use virtual functions, not function pointers....

> No MMX alpha blending blitter

While they could have benefitted from this, I myself will not (Since I am using OpenGL I let the graphics card do this, not software)...

> Also, alot of unnecessairy checks are done during the drawing of the sprites.

Again, the performace impact is negligible. In fact, the suggestion you make would actually cost more than a simple comparison because of the need to dereference the function pointer

> This removes alot of checks and wasted cpu cycles, so speed improvements should be noticed!

Afraid not. You could easily spend weeks implementing these changes only to discover that you gained a whooping 0.1 frames/second. What you're doing is called micro-optimising, which is totally useless unless you're in a loop that gets repeated many hundreds of thousands of times per second (the software blitter you mentioned above would be a suitable candidate for these sort of optimisations...if we didn't have hardware to do it for us).

What you want to look at instead is the high-level algorithms used. And then post your findings, please....I'm really curious, since I don't have the time myself, and it's a lot of work and all...


MOG

I hear a strange voice saying CHAMPAGNE :unsure:

[MOG Hackintosh]

I hear a strange voice saying CHAMPAGNE :unsure:

Why, it's JUBILATION T. CORNPONE!

Though he's gone to his reward, his mighty torch is still lit.
First in war. First in peace. First to holler, "I quit!"
Jubilation T. Cornpone!

When it seemed like our brave boys would keep on fighting for months,
Who took pity on them and ca-pit-u-lated at once?
Why it was Jubilation T. Cornpone! Unshaven and shorn - pone.
Jubilation T. Cornpone, he weren't nobody's dunce!

Who went re-con-noiter-ing to flank the enemy's rear,
Circled through the piney woods, and disappeared for a year?
Why it was Jubilation T. Cornpone;
Old "Treat 'em with scorn - pone."
Jubilation T. Cornpone, the missing mountaineer!

Who became so famous with a reputation so great,
That he ran for president and didn't carry a state?
Why it was Jubilation T. Cornpone;
Old "Wouldn't be sworn - pone."
Jubilation T. Cornpone, he made the country wait!

There at Appomatox Lee and Grant were present, of course.
As Lee swept a tear away, who swept the back of his horse?
Why it was Jubilation T. Cornpone!

That will be three dollars and feef-tee-three cents.


MOG

[Slayer]

Well, you STILL owe me 50% on $8, something.


[edited overlong quote]