GFX programming trouble

Toggle sidebar Toggle sidebar
G

Guest

Guest
Archived from groups: rec.games.roguelike.development (More info?)

I've encountered a problem while trying to create a graphical version of my
game. It's an ugly display bug I can't explain. I've tried anything I could
think of to fix it - without success. Of course I don't know the first thing
about graphics programming so maybe someone with more experience in this
field could tell me what can cause such behaviour. It seems like the screen
updates are too slow but that makes no sense cause the game uses DirectX
(through Allegro - the driver is set to AUTODETECT at the moment but I've
tried it with explicitly requested DirectX acceleration and their was no
noticeable improvement).

You can download the current in-dev version of TOD here:
http://todoom.sourceforge.net/todoom-bug.zip
(NOT playable! This download is only made available because of this bug.
It's Windows-only, too. I develop on Windows and this version hasn't been
ported to Linux yet)

Steps to reproduce the bug:
1. Choose "Continue old game" on the startup screen.
2. Move left or right a few steps to see the effect (look at the pools of
blood!)

Any idea what might be wrong?
(you can look at the code too, it's included. sd-alleg.c contains all the
low-level graphics code.)

Hopefully someone will be able to tell me what's wrong 'cause otherwise the
"TOD-graphical" project is pretty much dead 'cause I won't release something
which has such ugly display bugs (and as I said before I've run out of ideas
to fix it).

(the bug could be described as "flicker" but the game DOES use
double-buffering already - see sd-alleg.c)

TIA,
copx
 
Archived from groups: rec.games.roguelike.development (More info?)

Are you locking the dx surface (the allegro screen bitmap) before each
update and unlocking after each update? If not, it will be locking it
for each step of each update such as each tile blitted onto the screen.
In DX, locking is expensive. This could therefore be causing slow updates.

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."
 
Archived from groups: rec.games.roguelike.development (More info?)

copx wrote:
> Without double buffering (writing every tile and character to screen
> seperately) everything flickers like hell

Don't tell me you are showing the double buffer each time one
tile is drawn?:) No wonder it's slow:)
 
Archived from groups: rec.games.roguelike.development (More info?)

Uzytkownik "copx" <invalid@invalid.com> napisal w wiadomosci
news:d66tls$n1h$01$1@news.t-online.com...
> I've encountered a problem while trying to create a graphical
> version of my game. It's an ugly display bug I can't explain. I've
> tried anything I could think of to fix it - without success. Of
> course I don't know the first thing about graphics programming so
> maybe someone with more experience in this field could tell me what
> can cause such behaviour. It seems like the screen updates are too
> slow but that makes no sense cause the game uses DirectX (through
> Allegro - the driver is set to AUTODETECT at the moment but I've
> tried it with explicitly requested DirectX acceleration and their
> was no noticeable improvement).

I could not reproduce the problem, it doesn't flicker on my machine.
- what does it look like in full screen mode? (add vsync before
trying, this will tell you, if your drawing time exceeds one frame)
- are you sure you need double buffer? It adds a transfer of 1,5 mega
per frame of animation, and is pointless if not vsynced

regards,
Filip
 
Archived from groups: rec.games.roguelike.development (More info?)

"Filip Dreger" <fdreger@amiga.pl> schrieb im Newsbeitrag
news:d6754s$t87$1@nemesis.news.tpi.pl...
> Uzytkownik "copx" <invalid@invalid.com> napisal w wiadomosci
> news:d66tls$n1h$01$1@news.t-online.com...
>> I've encountered a problem while trying to create a graphical version of
>> my game. It's an ugly display bug I can't explain. I've tried anything I
>> could think of to fix it - without success. Of course I don't know the
>> first thing about graphics programming so maybe someone with more
>> experience in this field could tell me what can cause such behaviour. It
>> seems like the screen updates are too slow but that makes no sense cause
>> the game uses DirectX (through Allegro - the driver is set to AUTODETECT
>> at the moment but I've tried it with explicitly requested DirectX
>> acceleration and their was no noticeable improvement).
>
> I could not reproduce the problem, it doesn't flicker on my machine.

This bug gets stranger by the minute...
The character sprites don't flicker you know. The effect is only visible if
you look at the blood pools (and I've no idea why!)

> - what does it look like in full screen mode? (add vsync before trying,
> this will tell you, if your drawing time exceeds one frame)

How does vsync tell me that? (Sorry, I really know nothing about GFX
programming)
The Allegro docu says vsync isn't needed normally and the function returns
no values either...
Switching to full screen mode changes nothing...

> - are you sure you need double buffer? It adds a transfer of 1,5 mega per
> frame of animation, and is pointless if not vsynced

Without double buffering (writing every tile and character to screen
seperately) everything flickers like hell, in fact screen update is so slow
that the game is totally unplayable.
Calling vsync() has no noticeable effect..

copx
 
Archived from groups: rec.games.roguelike.development (More info?)

"Krice" <paulkp@mbnet.fi> schrieb im Newsbeitrag
news:1116160492.065479.232950@f14g2000cwb.googlegroups.com...
> copx wrote:
>> Without double buffering (writing every tile and character to screen
>> seperately) everything flickers like hell
>
> Don't tell me you are showing the double buffer each time one
> tile is drawn?:)

No, I don't do this.

copx
 
Archived from groups: rec.games.roguelike.development (More info?)

You probably got him killfiled, so:
Twisted One wrote:
> Are you locking the dx surface (the allegro screen bitmap) before each
> update and unlocking after each update? If not, it will be locking it
> for each step of each update such as each tile blitted onto the screen.
> In DX, locking is expensive. This could therefore be causing slow updates.
--
At your service,
Kornel Kisielewicz (charonATmagma-net.pl) [http://chaos.magma-net.pl]
"Come on, Kornel. 11 years and no binary? And it's not
vapourware?" -- Mike Blackney
 
Archived from groups: rec.games.roguelike.development (More info?)

Uzytkownik "copx" <invalid@invalid.com> napisal w wiadomosci
news:d67dve$14c$04$1@news.t-online.com...
> This bug gets stranger by the minute...
> The character sprites don't flicker you know. The effect is only
> visible if you look at the blood pools (and I've no idea why!)

I have no idea what you mean. The pools look like everything else and
don't flicker or anything; the game looks nice :).

If you really experience flickering (I don't), this may be a speed
issue. From what I have seen in your source you try to move around 3
megs of memory per screen update, and none of the memory is moved with
any hardware support (hardware support works only when you move things
inside your video memory, as the blitter of your video card can't
reach ordinary RAM). Moving this much may take more than 1/70 of
second (this is somewhere around the frame lenght), and if it does -
it can cause a flicker.

> How does vsync tell me that? (Sorry, I really know nothing about GFX
> programming)
> The Allegro docu says vsync isn't needed normally and the function
> returns no values either...

In case driver uses it (always under DOS), vsync() waits for the whole
screen to be redrawn by the monitor (pretty low level, huh?). If it
weren't for vsync, you could not avoid things like switching buffer
_while_ the screen is updated (this may be what your problem is, btw);
vsync can be used to detect if redrawing the whole screen takes more
than a frame (frame = time monitor needs to update the screen, if your
vsync=70Hz then your frame is 1/70 sec.).

There are three good ways of making your code much faster; each
requires some more changes in your current source and each is faster
than the other 🙂. Give me a couple of days, if I manage to build
todoom on my mingw machine, I will try the fixes and I will send the
results you.

regards,
Filip
 
Archived from groups: rec.games.roguelike.development (More info?)

"Filip Dreger" <fdreger@amiga.pl> schrieb im Newsbeitrag
news:d67uqf$aeq$1@nemesis.news.tpi.pl...
> Uzytkownik "copx" <invalid@invalid.com> napisal w wiadomosci
> news:d67dve$14c$04$1@news.t-online.com...
>> This bug gets stranger by the minute...
>> The character sprites don't flicker you know. The effect is only visible
>> if you look at the blood pools (and I've no idea why!)
>
> I have no idea what you mean. The pools look like everything else and
> don't flicker or anything; the game looks nice :).
>
> If you really experience flickering (I don't), this may be a speed issue.
> From what I have seen in your source you try to move around 3 megs of
> memory per screen update, and none of the memory is moved with any
> hardware support (hardware support works only when you move things inside
> your video memory, as the blitter of your video card can't reach ordinary
> RAM). Moving this much may take more than 1/70 of second (this is
> somewhere around the frame lenght), and if it does - it can cause a
> flicker.

As I said before I know nothing about graphics programming.
I just used the methods I've learned by reading a newbie tutorial...

>> How does vsync tell me that? (Sorry, I really know nothing about GFX
>> programming)
>> The Allegro docu says vsync isn't needed normally and the function
>> returns no values either...
>
> In case driver uses it (always under DOS), vsync() waits for the whole
> screen to be redrawn by the monitor (pretty low level, huh?). If it
> weren't for vsync, you could not avoid things like switching buffer
> _while_ the screen is updated (this may be what your problem is, btw);
> vsync can be used to detect if redrawing the whole screen takes more than
> a frame (frame = time monitor needs to update the screen, if your
> vsync=70Hz then your frame is 1/70 sec.).
>
> There are three good ways of making your code much faster; each requires
> some more changes in your current source and each is faster than the other
> 🙂. Give me a couple of days, if I manage to build todoom on my mingw
> machine, I will try the fixes and I will send the results you.

That would be really cool 🙂
Building TOD with mingw shouldn't be much of a problem 'cause I use that
compiler too. In fact the /src dir contains a mingw makefile (mingw.mak)
that should work out of the box (the game requires allegro 4.x and lua 5.x
to build, though ).
However I don't expect you to do my work. If you could just give me a few
hints on how I can improve the speed of my code I would happy.

copx
 
Archived from groups: rec.games.roguelike.development (More info?)

Uzytkownik "copx" <invalid@invalid.com> napisal w wiadomosci
news:d680ta$af8$04$1@news.t-online.com...

>> There are three good ways of making your code much faster; each
>> requires some more changes in your current source and each is
>> faster than the other 🙂. Give me a couple of days, if I manage to
>> build todoom on my mingw machine, I will try the fixes and I will
>> send the results you.
>
> That would be really cool 🙂
> Building TOD with mingw shouldn't be much of a problem 'cause I use
> that compiler too. In fact the /src dir contains a mingw makefile
> (mingw.mak) that should work out of the box (the game requires
> allegro 4.x and lua 5.x to build, though ).

I built it 🙂 (there are some probmems that I don't even want to
fathom with load_font, but overall, the game works; do you use any
font plugins?)
The problem is - I can't reproduce the problem 🙁
The game builds and works nice, no glitches or flickering... Unless I
can get todoom not to work on my machine, I can't be of much help 🙁
For now, I can only offer you some clues:
- it seems that you do not use hardware acceleration in your game -
it does not work (on most systems) when blitting from ordinary memory
to video ram, as the hardware blitter cannot reach anything beyond
VRAM. In most cases acceleration only works with video bitmaps and
system bitmaps If you change:
ScreenBuffer=create_bitmap(...
to:
ScreenBuffer=create_system_bitmap(...
you should get much better performance. You can check which operations
are accelerated in your system, and which are not, by running the
"test.exe" found in allegro\tests and choosing misc->accel. features.
Currently you are using only mem->vram.
- you might want to move sprites to system bitmaps as well
- if this does not help, maybe you should think about keeping both
the screen and the buffer in VRAM, and switch between them by
scrolling (might not be possible in windowed, but would work great
under dos)
- unless your computer is really slow, maybe the problem lies
somewhere else, not in the speed? I have not looked at any part of the
code that calls the functions in sd-alleg...

hope this helps...
Filip
 
Archived from groups: rec.games.roguelike.development (More info?)

copx wrote:
> I've decided to abandon the graphical version of TOD. I hate dealing
with
> such non-gameplay related stuff and it really slowed down my
progress.

Don't give up so soon. There are so much advantages in graphics.
One thing I was wondering is draw_tile_at(). There is
something going on in that routine.. I'm wondering the way you
call draw_tile_at from the same routine. I guess that is legal,
but still..
Btw, I could not see the problem either. It can be seen only in
slower machines I guess.
 
Archived from groups: rec.games.roguelike.development (More info?)

copx wrote:
> I've tried to fix this problem for over a week now. It's goddamn
> frustrating.

I tried to compile it and possibly fix the bug, but I was missing
at least lua libraries:)

> Only if you make good use of them. Just replacing ASCII characters
with
> sprites (which is probably all I'll ever do) has no advantage except
that
> your target audiance becomes a little larger.

With graphics you can represent things better. For example if you
draw item frames for all items then you don't need to go and check
all ('s or !'s or whatever. You can see right away is the stuff
something worth picking up. And the most important thing is that
there is no limitation for tiles like in ASCII, which is very limited
especially for terrain.

> that you need to draw a new piece of art everytime you want to add
something
> to the game. That takes lots of time.

When I was unable to compile TOD I made new tiles (only those on the
screenshot) with Stile in 15 minutes or so.. The new wall is horrible:)

http://koti.mbnet.fi/paulkp/temp/tod.jpg

> My machine isn't slow. It plays all other games just well.
> So there most be something wrong...

It might be an issue with Allegro itself. I guess someone else has
noticed this too, if for example some video card and Allegro doesn't
work together. I wonder is there Allegro forum to search for such
problems...
 
Archived from groups: rec.games.roguelike.development (More info?)

"Filip Dreger" <fdreger@amiga.pl> schrieb im Newsbeitrag
news:d68bts$3jq$1@nemesis.news.tpi.pl...
[snip]
> I built it 🙂 (there are some probmems that I don't even want to fathom
> with load_font, but overall, the game works; do you use any font plugins?)

No, just Allegro's standard functions.

> The problem is - I can't reproduce the problem 🙁
> The game builds and works nice, no glitches or flickering... Unless I can
> get todoom not to work on my machine, I can't be of much help 🙁
> For now, I can only offer you some clues:
> - it seems that you do not use hardware acceleration in your game - it
> does not work (on most systems) when blitting from ordinary memory to
> video ram, as the hardware blitter cannot reach anything beyond VRAM. In
> most cases acceleration only works with video bitmaps and system bitmaps
> If you change:
> ScreenBuffer=create_bitmap(...
> to:
> ScreenBuffer=create_system_bitmap(...

I tried this: no noticeable effect. It seems that performance isn't the
problem after all. To test it I switched to the GDI driver which is supposed
to be horribly slow.. again no noticeable effect. I guess in the case of a
primitive tile-based game running on a modern Ghz/8x AGP system such stuff
doesn't matter anymore.

[snip]
> - unless your computer is really slow, maybe the problem lies somewhere
> else, not in the speed? I have not looked at any part of the code that
> calls the functions in sd-alleg...

The rest of the code can't be the problem either. To test I did a hack to
make sure that the screen is only updated once per turn.
So the flicker can't be explained by superfluous screen updates either..

I've decided to abandon the graphical version of TOD. I hate dealing with
such non-gameplay related stuff and it really slowed down my progress.
Just one of many misguided ideas I guess..

Thank you for trying to help me, though.

copx
 
Archived from groups: rec.games.roguelike.development (More info?)

"Krice" <paulkp@mbnet.fi> schrieb im Newsbeitrag
news:1116236200.968968.11990@z14g2000cwz.googlegroups.com...
> copx wrote:
>> I've decided to abandon the graphical version of TOD. I hate dealing
> with
>> such non-gameplay related stuff and it really slowed down my
> progress.
>
> Don't give up so soon.

I've tried to fix this problem for over a week now. It's goddamn
frustrating.
I'm totally sick of it.

> There are so much advantages in graphics.

Only if you make good use of them. Just replacing ASCII characters with
sprites (which is probably all I'll ever do) has no advantage except that
your target audiance becomes a little larger. The serious disadvantage is
that you need to draw a new piece of art everytime you want to add something
to the game. That takes lots of time.

> One thing I was wondering is draw_tile_at(). There is
> something going on in that routine.. I'm wondering the way you
> call draw_tile_at from the same routine. I guess that is legal,
> but still..

It's perfectly legal. The cool kids call it "recursion" ;-)
No, that's not the problem.

> Btw, I could not see the problem either. It can be seen only in
> slower machines I guess.

My machine isn't slow. It plays all other games just well.
So there most be something wrong...


copx
 
Archived from groups: rec.games.roguelike.development (More info?)

Uzytkownik "Krice" <paulkp@mbnet.fi> napisal w wiadomosci
news:1116248690.559740.138470@g44g2000cwa.googlegroups.com...
> I tried to compile it and possibly fix the bug, but I was missing
> at least lua libraries:)

I simply downloaded the libraries, wasn't so hard :)

> When I was unable to compile TOD I made new tiles (only those on the
> screenshot) with Stile in 15 minutes or so.. The new wall is
> horrible:)
>
> http://koti.mbnet.fi/paulkp/temp/tod.jpg
>
>> My machine isn't slow. It plays all other games just well.
>> So there most be something wrong...
>
> It might be an issue with Allegro itself. I guess someone else has
> noticed this too, if for example some video card and Allegro doesn't
> work together. I wonder is there Allegro forum to search for such
> problems...

http://www.allegro.cc/forums/

I was waiting for someone to bring this about. Well, we have a saying
here in Poland: "u mnie dziala" 😉

regards,
Filip
 
Archived from groups: rec.games.roguelike.development (More info?)

In article <d66tls$n1h$01$1@news.t-online.com>, "copx" <invalid@invalid.com> wrote:
>Steps to reproduce the bug:
>1. Choose "Continue old game" on the startup screen.
>2. Move left or right a few steps to see the effect (look at the pools of
>blood!)

I didn't see any flickering on my machine. The game did use 97% of cpu
though, and the fan on the laptop had to go into high gear.

Alan
 
Archived from groups: rec.games.roguelike.development (More info?)

"Krice" <paulkp@mbnet.fi> schrieb im Newsbeitrag
news:1116248690.559740.138470@g44g2000cwa.googlegroups.com...
[nip]
> TOD I made new tiles (only those on the
> screenshot) with Stile in 15 minutes or so.. The new wall is horrible:)
>
> http://koti.mbnet.fi/paulkp/temp/tod.jpg

Well, I can't draw so I need more time. The new blood is great but the walls
and doors are totally out of theme (TOD is SF and the walls and doors look
medieval).

>> My machine isn't slow. It plays all other games just well.
>> So there most be something wrong...
>
> It might be an issue with Allegro itself. I guess someone else has
> noticed this too, if for example some video card and Allegro doesn't
> work together. I wonder is there Allegro forum to search for such
> problems...

Whatever. TOD-graphical is dead. I want to go back doing things I actually
like.

copx
 
Archived from groups: rec.games.roguelike.development (More info?)

copx wrote:
> and doors are totally out of theme (TOD is SF and the walls and doors
look
> medieval).

It didn't look like SF:)

> Whatever. TOD-graphical is dead. I want to go back doing things I
actually
> like.

You can develop it with ascii and perhaps later make a graphical
version.
When/if you decide to do that, I can recommend SDL as graphics library.
I'm using it in three of my current projects (Kaduria, Stile & Xirtrix
v3)
without problems. As you might know it's much simple than Allegro
and doesn't have Allegro's "low level" approach. Just couple of
functions to deal with.
 
Archived from groups: rec.games.roguelike.development (More info?)

R. Alan Monroe wrote:
> The game did use 97% of cpu
> though, and the fan on the laptop had to go into high gear.

This is a feature of SDL too. Graphics libraries seem to need all
the speed so they grab all processor time.. I have heard that you
can fool SDL to drop that demand by adding SDL_Delay(1) or something
inside the event loop. Haven't yet tried that, but people complained
about Stile taking all processor time so I'm giving it a try.
 
Archived from groups: rec.games.roguelike.development (More info?)

Steve Yrjana wrote:
> This is not a feature of any library, it's a feature of your own
code.
> If you busy loop, then of course all CPU is eaten.

I guess you can say it that way, too. But since there is only one
way (afaik) to use SDL_PollEvent, then it's a feature of SDL:)

> Or better yet, don't use busy looping/polling in a roguelike where
the
> game is frozen while waiting for input from the user (unless you have
some
> background stuff going on, like animation). This is best done with
SDL by
> using SDL_WaitEvent() instead of SDL_PollEvent().

Thanks. I will try that.
 
Archived from groups: rec.games.roguelike.development (More info?)

Dnia 17 May 2005 03:01:58 -0700,
Krice napisal(a):

> R. Alan Monroe wrote:
>> The game did use 97% of cpu
>> though, and the fan on the laptop had to go into high gear.

> This is a feature of SDL too. Graphics libraries seem to need all
> the speed so they grab all processor time.. I have heard that you
> can fool SDL to drop that demand by adding SDL_Delay(1) or something
> inside the event loop. Haven't yet tried that, but people complained
> about Stile taking all processor time so I'm giving it a try.

I don't know about SDL in general, but in PyGame it only depends
on what function you use to do delays.

From the docs:

delay
pygame.time.delay(millseconds) -> time

Will pause for a given number of milliseconds. This function will
use the CPU in order to make the delay more accurate than wait().

wait
pygame.time.wait(millseconds) -> time

Will pause for a given number of milliseconds. This function sleeps
the process to better share the CPU with other processes. It is less
accurate than the delay() function.

In a roguelike without animated tiles you'd rather want to use this:

wait
pygame.event.wait() -> Event

Returns the current event on the queue. If there are no messages
waiting on the queue, this will not return until one is available.
Sometimes it is important to use this wait to get events from the queue,
it will allow your application to idle when the user isn't doing anything
with it.

--
Radomir @**@_ Bee! The quest for the Real World:
`The Sheep' ('') 3 Try #1: cd /..
Dopieralski .vvVvVVVVVvVVVvv.
 
Archived from groups: rec.games.roguelike.development (More info?)

On Tue, 17 May 2005 03:01:58 -0700, Krice wrote:
> R. Alan Monroe wrote:
>> The game did use 97% of cpu
>> though, and the fan on the laptop had to go into high gear.
>
> This is a feature of SDL too. Graphics libraries seem to need all
> the speed so they grab all processor time.. I have heard that you

This is not a feature of any library, it's a feature of your own code.
If you busy loop, then of course all CPU is eaten.


> can fool SDL to drop that demand by adding SDL_Delay(1) or something
> inside the event loop. Haven't yet tried that, but people complained
> about Stile taking all processor time so I'm giving it a try.

There is nothing fooling of SDL or Allegro, it's the operating system
that handles the timeslicing of CPU time.


One solution is to set maximum framerate with SDL_gfx like this:

#include <SDL/SDL_framerate.h>

....
FPSmanager framerate_manager;
SDL_initFramerate(&framerate_manager);
SDL_setFramerate(&framerate_manager, 50);

while(1)
{
/* do frame stuff */
SDL_framerateDelay(&framerate_manager);
}


Or better yet, don't use busy looping/polling in a roguelike where the
game is frozen while waiting for input from the user (unless you have some
background stuff going on, like animation). This is best done with SDL by
using SDL_WaitEvent() instead of SDL_PollEvent().


Regards,

--
joni
 
Archived from groups: rec.games.roguelike.development (More info?)

Filip Dreger wrote:
> I was waiting for someone to bring this about. Well, we have a saying
> here in Poland: "u mnie dziala" 😉

No, you don't. That phrase has far too many vowels. Heck, it has no ws
or cs and only one z so it can't possibly be Polish. 😉

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."
 
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom