Page 2 of 2
Posted: Wed Oct 12, 2005 9:25 pm
by dracflamloc
Linux has no DirectDraw. It uses it's own, which most likely would run faster for your card.
I've run a pb sprite program on a 400mhz computer with a reasonable graphics card and it ran acceptably.
Posted: Thu Oct 13, 2005 10:21 am
by Num3
Checked the code and in the main loop you use this every flipbuffer()
Code: Select all
ClipSprite(#SPRITE_TILESET_ITEMS, 192, 288, 32, 32)
DisplayTransparentSprite(#SPRITE_TILESET_ITEMS, mmouse_x, mmouse_y)
Why just don't you clip the mouse sprite at the beginning and only change it when it's needed too ?
Also, only open a 32bit screen on top computers, old machines don't support it and run too slow (even some linux distros don't support 32bits screens), always try a 24bit screen!
Don't use SetFrameRate(60), FlipBuffer() is by default synchronization enabled, and i've had the experience of games crashing on some windows machines when you're forcing the refresh rate (mostly ATI cards with hardware forced framerate<>60)
Posted: Fri Oct 14, 2005 12:29 am
by Kaiser
Can't help ya much there, other than suggesting the same thing that dracflamloc said. Looks really good though.
I agree, Linux is faster with 2D apps than Windows is... happened to me with DOSBox running Stargunner in Linux: No choppy sound and faster loading time, though with Windows, using the same settings, it came with choppy sound :/ (due to framerate, which was more in Linux)...
Num3:
Nice code suggestion
but the 24bit screen isn't really good, would prefer 16-bit: More compatible, faster, and it's supported by all cards (for example, my inboard SiS 630/730 AGP doesn't supports 24-bit, but does 16 and 32. Weird, heh, and crashes (of course) with a 24-bit app :/
Posted: Fri Oct 14, 2005 2:38 am
by Brujah
Okay, I will remove the SetFrameRate Setting.
And initialize the screen to 16 Bit. Our Game does not need more colors!
I just remember that it didn't run on windows like this a long time ago...
Have to try if its working now.
Posted: Sat Oct 15, 2005 4:49 am
by Brice Manuel
I just remember that it didn't run on windows like this a long time ago...
You are not alone. I ran into a similar problem today with a pb test exe using DirectDraw running very slow on three systems with MOBO vchips that I know darn well used to run the same exe fine with no horrible slow down. Drivers are up to date, as is DX, BIOS settings are correct for the vchips. However, OpenGL is running fine on those systems.
Posted: Sun Oct 23, 2005 1:06 am
by dagcrack
Brice Manuel wrote:If you are using a Nvidia card, try updating your drivers. Some versions are buggy when it comes to displaying text on the screen and will choke, dunno if this carries to linux or not.
Very nice looking game
This is like saying that bread makes you fat!! - depends what bread and how much you eat of it, but anyway only very vague / poor implementations of text routines will cause you slowdowns...
I remember reading that same "buggy when it comes to displaying text on the screen and will choke" on blitzbasic forums ............. :roll: ...................sad.
Adding to the issue, I didnt check your game Brujah, but its sure your notebook integrated gpu.