Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

2D All the way! / DBP: Sprite Redrawing Issue

Author
Message
megamanx
20
Years of Service
User Offline
Joined: 17th Jun 2004
Location: Kentucky, USA
Posted: 18th Jun 2004 14:53
Link
I have started working on a small project to see if I can emulate one of the SNES megaman games in functionality. I just now got the sprite movement functionality added, which seems to be causing a problem. If you move the sprite left or right, it will leave leave a trail or sprites or it's simply not redrawing correctly, I'm unsure of what the actual problem is. Here is my current code...



here is the sprite that I'm using...




Can somebody please tell me what I'm doing wrong and how I can fix it? I would greatly appreciate it.
Back to top
Profile PM Email
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 18th Jun 2004 15:45
Link
You just need to clear the display each frame.

*** Coming soon - Network Plug-in - Check my site for info ***
For free Plug-ins, source and the Interface library for Visual C++ 6, .NET and now for Dev-C++ http://www.matrix1.demon.co.uk
Back to top
Profile PM Email Website
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 18th Jun 2004 16:16
Link
as IanM said just add a cls to the beginning of your main loop.




Back to top
Profile PM Email
megamanx
20
Years of Service
User Offline
Joined: 17th Jun 2004
Location: Kentucky, USA
Posted: 18th Jun 2004 17:17
Link
Aaaah, now it makes sense. Thanks for the help Ian and Zenassem
Back to top
Profile PM Email
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 19th Jun 2004 01:36 Edited at: 19th Jun 2004 21:05
Link
megamanx,

This may also be of interest to you. (You can thank IanM for this as well, because he past it along to me.)

Your going to want to make sure that the game objects move at the same rate. Here's away to make lock in the framerate. adjust the "10" (/ by number) for different rates. Here movetimerset# is = to 100.





Back to top
Profile PM Email
megamanx
20
Years of Service
User Offline
Joined: 17th Jun 2004
Location: Kentucky, USA
Posted: 19th Jun 2004 14:25
Link
I do not understand why I'd need that. Can you please explain a scenario where this is, and isn't, used in a game and what difference it makes?
Back to top
Profile PM Email
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 19th Jun 2004 20:48 Edited at: 19th Jun 2004 21:24
Link
Megamanx,

[edit]OOps! I noticed a mistake in my code above. The 'sync' command should be outside the if condition. I edited it. Now it should make more sense.

I understand your confusion, it's not intuitive at first. It's actually easier to understand when seeing an example than it is to explain it, but I will do my best.

For my explanation think of the game Mortal Kombat. The characters(sprites) have multiple frames of animation while standing still. (They are moving in a fighting stance, breathing etc)

Now say we set the sync rate to 60 frames per second in our application. This only makes sure that the screen is refreshed 60 times per second. It has no control over how often the code in our loop is processed. In other words, it doesn't control the timing of the loop.

So what will happen without this code I provided?

The screen fps will be at 60 but the loop may be running through itself at a faster rate. This would result in you missing frames of animation, and the charaters movements will be out of sync with the frame rate. The animations of the sprite will be fast and jerky.

Solution:
By adding the frame limiter code in my last post. It forces the main loop to be in sync with the frame rate, thereby providing a smooth animation.


note: A common mistake that some may make (and I have done it as well) is to do one of two things. The first is to put wait statements in the internal loop to slow it down. Unfortunately this results in slowing down the loops ability to reach the sync command. Or they will have more than one frame of animation in the internal loop. This is also not good, and creates a disaster for controlling the animation speed of multiple objects.

You aren't noticing the effects in your code right now because your sprite doesn't yet have internal sprite frame animation. I used the mortal kombat example only because most people will know it. But the frame code is generally needed in any sprite based game where the character or other sprite has animation frames for every cycle of the loop.

Which is generally most games, especially ones that look interesting. Games that have sprites that are just still unless they are walking are less interesting and appealing. The code is necessary for any sprites that have an internal animation cycle. Examples could be >flickering fire from a candle, moving water tiles in a 2d adventure, etc..


Back to top
Profile PM Email
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 19th Jun 2004 21:17
Link
The point that he's trying to make is that the standard DirectX frame rates are actually not that accurate.

Using a sync rate of 60, you might get a rate anywhere from 60 to 70 fps, making your game run faster on some machines. You can try this yourself



I get 66 fps with that code on my laptop.

The alternate method is to do the timing of the frame flips yourself. I've got a few functions that I'll use for that when I need accurate frame rates, which you can try yourself



You should get much more accurate results from that, although the standard windows timer is also a little 'off' sometimes. In my own code, I simply use the HITIMER() function built into my utility plug-in, where I can get exact frame rates.



So, there you are - all you never wanted to know about sync rates, and more

*** Coming soon - Network Plug-in - Check my site for info ***
For free Plug-ins, source and the Interface library for Visual C++ 6, .NET and now for Dev-C++ http://www.matrix1.demon.co.uk
Back to top
Profile PM Email Website
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 19th Jun 2004 21:43 Edited at: 19th Jun 2004 21:49
Link
IanM,

It's even worse than just a slight inaccuracy of the refresh rate.

I've done some tests with my Streets of Rage game.

If I don't use the code you provided, my characters internal animation is not in sync with the refresh rate. So if i just set the sync rate to 60 and print the screen FPS() I get something close to 60. But the character frames are cycling through at a faster rate.

With the code above. I still get a FPS() rate of something close to 60. But the characters animation frames are in sync. So, His animation frames are cycling once per screen refresh and I'm not missing any frames when I sync.

The best way I can describe this is: It appears that with just setting the sync rate my code is actually running through the loop more times then is being displayed by the sync refresh. This is disasterous as I update the sprite frames every loop. So if I don't sync the internal loop to the sync rate, I may only see every other frame of animation. It makes my charachter look as though he's hyped up on caffien or being electricuted rather than bouncing gracefully in a fighter stance.

So I'm not sure that I am technically correct but, my observations lead me to believe that the sync rate and sync command only control how often the screen will be refreshed. It does not prevent the code in your loop from being processed more times than the screen is being redrawn. This is not good if you are incrementing you sprite frames every iteration of the loop. It's so hard to describe in words, but the effects are clear as night and day when observing the difference. I know there are methods to use like the ones you provided, but the snippet I posted is quite simple and easy to implement. Before you provided me with that snippet, I had to reduce the sync rate in order to slow down the animation rate of my character. As you can guess this is not a good method.

Last example and attempt to describe the issue.
Look at my animated gif below. If I were to put him in my game without the code snippet and set the sync rate to say 60. He would appear to cycyling through his animation at light speed. Kind of akin to watching old films of babe ruth running the bases. Printing the fps() would show a result of something close to 60fps.

Now if i include the frame timer code above and setting the sync rate to 60. the character will move fluidly like the animated gif below. Printing the fps() would still result something close to 60fps. So the code, is basically making sure that the loop is being processed in accordance with the sync/refresh rate.


Back to top
Profile PM Email
megamanx
20
Years of Service
User Offline
Joined: 17th Jun 2004
Location: Kentucky, USA
Posted: 19th Jun 2004 23:12
Link
Oh, ok. The sync rate only controls the refresh rate and not the running rate, gotcha
Back to top
Profile PM Email
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 20th Jun 2004 01:38 Edited at: 20th Jun 2004 01:59
Link
@megamanx,

You just said everything I posted in 1 line.


I really need to take my meds

I wasn't sure if anyone would understand what the heck I was talking about.

note:I should state that the way I have handled sprite animation, is
to change the sprites image# and redrawing it. I haven't been
able to have DBpro's built-in sprite animation commands work for me.
So the issue I'm describing may be because of the overall method I use
to produce animated sprites. I would apprecitate it if someone who has
been successful in using the "Play Sprite" command (which has a delay)
parameter could explain it to me. It's possible it has been fixed
since I last tried to figure it out.
-----------------------------------


But still, I'm just describing what appears to be happening.
I would still like someone to confirm that this is actually
the case. Either way, the timer snippet works to fix the
problem.

Before receiving that snippet from IanM, I would hold a mod count
for every iteration of the loop. Then perform the increment of the
next animation frame every 4th iteration or so. This would slow down the animation sequence without jepardizing the frames per second rate
for the rest of the game. This is a pain if you need to have different
sprites moving at different speeds.

I guess another answer is to have duplicate a # frames for each sprite
to control how fast they animate, while leaving the sync rate in tact.
----------------------------------------------------------------------



So here's my question.
Does anyone have a better method for controlling how fast a sprite
goes through it's animation frames while leaving the sync/refresh rate
alone? What about multiple sprites cycling at different speeds? Do you
just pad all sprites to have the same number of frames (using
duplicate frames)?


Back to top
Profile PM Email
Neophyte
22
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 21st Jun 2004 02:00
Link
@zenassem

"Does anyone have a better method for controlling how fast a sprite
goes through it's animation frames while leaving the sync/refresh rate alone?"

I think I have a pretty decent system currently and it works rather smoothly. If you can start up that Iso thread and post what code you have(which looks to be rather complete judging by what you posted in the Question About Drawing Layers of Tiles thread), I could adapt my functions to your code rather easily. I've been meaning to rewrite some of my animation routines to be more efficent anyway, but the basic system I've got down is pretty solid from the current tests I've done with it so far.
Back to top
Profile PM
M00NSHiNE
21
Years of Service
User Offline
Joined: 4th Aug 2003
Location: England, UK
Posted: 21st Jun 2004 02:55
Link
Aparrenly, whereby in the Windows API theres the DWORD GetTickCount(void) function to get the Windows system time, theres something much faster and more accurate, but it would probably require a DLL for it to be implemented into DBPro.

Theyre called:

BOOL QueryPerformanceFrequency
(LARGE_INTEGER *lpFrequency)

BOOL QueryPerformanceCounter
(LARGE_INTEGER *lpCount)

Include : WINBASE.H
Library : KERNAL32.LIB

I found this on a site comparing timer systems. this is the best one, but its not available on all machine apparently.

http://www.mvps.org/directx/articles/selecting_timer_functions.htm

Back to top
Profile PM
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 21st Jun 2004 03:36
Link
@Moonshine,

Thanks! You hit the nail on the head. That's why these questions are coming up for me.

I am trying to rework some of my example code for the tutorial and I'm realizing that there are issues like this one, that I haven't addressed. Using workarounds or obfuscated solutions is ok in my own code, but it doesn't boast well in a tutorial that is aimed at helping people. Especially because I'm attempting to clear up the confusion of 2D in DBpro.

Messy Solution
-> The way I've gotten around the issue is to have each sprite in my projects have it's own timing code in a userdefined type. The complexity of managing each individual animated sprite is laborous to say the least. And without object oriented classes, It's frankly a messy solution at best. Especially if tiles themselves are animated sprites.

(Although someone informed me that the <play sprite> command works as long as long as the frame order is sequential and doesn't change the frame sequence. This will work well for most animated tiles. Not for characters that can change direction and stop moving all together).

The last thing I am contemplating is:
Im some of my work I use images for tiles. I am trying to decide wheteher it's best to use sprites. The problem intorduced itself when I was working with DBC, it seemed to like the images better. Now with DBpro, being that sprites are handled by 3D accelration, it may be better to have all the tiles as sprites.

Do you have any suggestions on which way to go?

I'm going to post the thread today. We will work out the issues as we go along. There's hardly ever one right way for all situations.

~Zen


Back to top
Profile PM Email
M00NSHiNE
21
Years of Service
User Offline
Joined: 4th Aug 2003
Location: England, UK
Posted: 21st Jun 2004 03:49
Link
Id go with sprites for tiles as you could apply more effects and take advantage of hardware acceleration

Back to top
Profile PM
Neophyte
22
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 21st Jun 2004 04:26
Link
@zenassem

"The way I've gotten around the issue is to have each sprite in my projects have it's own timing code in a userdefined type. The complexity of managing each individual animated sprite is laborous to say the least."

That's the way I do it. I haven't had too much trouble with it really. The only problem that I have is the way I select the frames and that really isn't related to the timing issue at all. Thanks to Lee's suggestion I'm going to use a different and more efficent method.

"I am trying to decide wheteher it's best to use sprites. "

I'll have to disagree with M00NSHiNE on this and go with images pasted into bitmap zero for tiles. Its much simpler and beats having to clone lots of sprites and the complexities that can rise from that. Or at least that's what I've found out.

Characters, however, should probably be done with sprites. It's taking too much work to paste them properly into a bitmap when they have a ton of animation frames you have to sort through. I've found this out the hardway unfortunately, and I'm planing on fixing it by using the Set Sprite TexCoord command like Lee suggested.

"I'm going to post the thread today."

Good to hear.

I'll integrate my animation code with your posted code and make my own post in that thread explaining how I did it. Hopefully, that won't take me too long.
Back to top
Profile PM
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 21st Jun 2004 07:19
Link
@neophyte,

Thanks for the help. I'm real curious as to the details of lee's suggestion. Can you share this with us?

I am waiting for a response from a post I have in the "DarkBasic Pro" board. Perhaps you can test my code snippet there to see if it's just something that is happening on my computer. Here's the link to the post...

http://darkbasicpro.thegamecreators.com/?m=forum_view&t=33787&b=1


Back to top
Profile PM Email
Neophyte
22
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 21st Jun 2004 07:59
Link
@zenassem

" I'm real curious as to the details of lee's suggestion. Can you share this with us?"

Sure. My problem was with trying to create an animated character for my game. I couldn't use create animated sprite because there is no position sprite command. The only way to position a sprite is to use the sprite command and well that just removes any effect that create animated sprite might of had(this is all to the best of my knowledge. If you know of a way to move a sprite with out using the sprite command I'm all ears). The only way to move an animated sprite was to use the move sprite command and that can be rather hard to work with in an iso game.

So I was talking about a some new commands to get around this when Lee suggested that what I wanted could be achieved with the Set Sprite TexCoord command. Basically, I use this command to specify what sections of my sprite are to be displayed by modifying the UV coords for the image associated with the sprite. It allows me to simulate the create animated sprite command essentially.

That in essence is what I'm going to be rewritting my animation commands to do.

"I am waiting for a response from a post I have in the "DarkBasic Pro" board. Perhaps you can test my code snippet there to see if it's just something that is happening on my computer. "

That's the first time I've seen a problem like that. Then again, it took me a few looks before I realized the difference so I might not have noticed it before because I'm rather unobservant sometimes.

I'd post it in the bug report forum if you don't get a reply soon and see if anyone there has encountered this problem or can verify that it happens.
Back to top
Profile PM
Neophyte
22
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 23rd Jun 2004 13:09
Link
@zenassem

I've read the other thread and found out that you got the problem fixed. So does this mean that the much anticipated Iso thread is almost ready for launch?

(Sorry if I'm bugging you too much. I'm just really excited about making an iso thread and getting a chance to start writing tutorials and contributing to the community again. Its been a while since I've had the chance to.)
Back to top
Profile PM
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 23rd Jun 2004 22:51
Link
@neophyte,

No, your not bugging me. I probably spoke to soon.

I ran into some issues with my code, and I needed to make sure that the examples would work properly. I think I have a most of it sorted out now.

I also needed to look deeper into how I would start the thread. (My intent was to write tutorials that could be downloaded). I do like the idea of posting a thread. I think that through comments and feedback I will learn what works and what doesn't and it will help to create a better tutorial - which is still my goal in the end.

The thread format introduces it's own challenges however. The examples and code need to be presented in a way that everyone, including people who may be trying to understand tile-based game design for the first time. Keeping this in mind, I need to keep the beginning sample code as straight-foward as possible, (even though it wouldn't be an optimal solution), and allow the code to grow in complexity. I also would like to cover 2d top-down first. But that would mean a long period of time before getting to ISO.

I think that I'll start off simple, 2d top-down tiles, and take it up to where we have enough background to discuss ISO. Rather than trying to cover every advanced topic of 2d top-down.

I'm still not sure how well a thread format will work, but I guess we'll find out. I've been trying to look at some of the other 2d thread tutorials for pointers.

Lastly, I've been busy between work, and side-work, family and personal stuff, and haven't had as much time this past week as aniticipated. Especially after running into some snags with the code. I will really try to post the beginning of the thread as soon as possible.

~Zen


Back to top
Profile PM Email
Neophyte
22
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 24th Jun 2004 06:34
Link
@zenassem

"I think that I'll start off simple, 2d top-down tiles, and take it up to where we have enough background to discuss ISO."

Okay. In that case, I could probably help with the path finding early on. If you are doing a topdown view than something like IanM's A* pathfinding code would be ideal, and I have experience with that so I could help out there.

But I'm not entirely sure myself when we would introduce Iso layouts. Should the iso layout be grouped with the top-down layout or after we have a decent game that's running in a top-down layout?

I suppose after we have a decent framework up using the top-down view we could go with Iso, and show how to integrate it. How's that sound? I think it would be easier then.

"Lastly, I've been busy between work, and side-work, family and personal stuff, and haven't had as much time this past week as aniticipated."

Yeah, I know how that is.
Back to top
Profile PM
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 24th Jun 2004 23:21
Link
Neophyte,

Your suggestions sound good.

I was also thinking of starting a seperate thread that can deal with some of the 2D basics (images, sprites, bitmaps & such.) I have come across a lot of findings in getting 2d to work properly in dbpro. I could have a link from the tile/Iso thread to the general 2d thread. This will reduce the clutter in one single thread. As we build and get closer to actual ISO tiles we may decide to kick off a new thread for just ISO. It may also be possible to do all three threads at the same time.

This way beginners to 2d and tile based games can start with the general 2d thread & the top-down 2d tile maps. And the people who are already familiar with 2d and are in search ISO information, can just begin with the ISO thread. Instead of having to wait for the thread to get to ISO discussion. It may be confusing for some but I believe it's the only way to go.

1 thread for the general 2d information
1 thread for top-down 2d maps
1 thread for Iso maps

This will of course keep me plenty busy. Also, by doing it this way you can contribute some of your ISO stuff.

~zen


Back to top
Profile PM Email
Neophyte
22
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 25th Jun 2004 07:46
Link
@zenassem

"As we build and get closer to actual ISO tiles we may decide to kick off a new thread for just ISO. It may also be possible to do all three threads at the same time."

Interesting. I like the idea. I could get my ISO stuff out much faster this way.
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2025-05-15 15:46:28
Your offset time is: 2025-05-15 15:46:28