Scrolling Game Development Kit Forum
SGDK Version 2 => General Discussion => Topic started by: Orion Pax on 2006-02-05, 08:09:38 AM
-
Im curious how you might handle this in sgdk2. I consider the fact that game time is directly connected to FPS to be a disadvantage in 1.4.x. There is a frame limiter but it conflicts with vsync which will cause a nasty jitter if they don't match or if the frame limit isnt diviable, ex: 30 fps 60hz vsync. If a project ran slow frame skipping could be imployed to keep game time consistant as well as making sure the gaming experiene was roughly the same for all users. I don't know what frame skipping effects would be on collsion detection and the like though. If there will be any syncing with music it would be a futher concern. I also hope that you add vsync controls for running projects. It is true video drivers can force vsync on or off but the default is 'application specific' leaving the control to the application.
As this ties a bit into rendering and the fact you are using dx9/d3d I'd like to know if control of the render/blitting will be made avaible as far as linear (blur) or nearest ( blocky) and if the games intended resolution can be overidden by such. It is of particular importance for LCD's but in general as well. Game system emulators have to deal with some of this so perhaps lookinto into something like VBA http://vba.ngemu.com/ would be useful. Something that would be neat is the inclusion of visual filters that run independantly of the game/project in question. A resolution doubler, fake scan lines, fake lcd, motion blurr, etc. If you could invoke different filters per project that would be a plus too but I dont know how feasbile this would be. Motion bluring would rock though =]
I suppose this is pretty much engine related which I know hasnt started yet but just throwing some ideas and thoughts out there. I really do want to see some measures taken to insure the game i run locally runs the same speed for someone else. The frame limiter in 1.4 feels like something incomplete and hacked in.
Render effects
I'm hoping that there will be some tools for lighting and other effects. SGDK2 will be dx9 and its pretty much the norm for modern 2d games. example: If I'm iin the dark but have a glow around the player to see what is immediatly infront of me or there is an explosion/ etc producting light. The level editor could drop various styles of lights like droping a path on a map, be it fixed, moving or in relation to a sprite/object. Particle effects for exploisions, weapons, etc could be scriptable.
With translucany I can do a lot of things like shadow maps via tiles but dynamic lighting will be more tricky depending. Basiclly I'm lookin for coded effects where producing them from a png/file is not the best option. This could be considerd for transition effects, fading or flashing a screen to a color etc as well. I suppose I am invisioning a gfx scripting engine for effects plus light droppin on map. Feel free to tell me I'm out of my gord for the request =P
-
Im curious how you might handle this in sgdk2. I consider the fact that game time is directly connected to FPS to be a disadvantage in 1.4.x. There is a frame limiter but it conflicts with vsync which will cause a nasty jitter if they don't match or if the frame limit isnt diviable, ex: 30 fps 60hz vsync. If a project ran slow frame skipping could be imployed to keep game time consistant as well as making sure the gaming experiene was roughly the same for all users. I don't know what frame skipping effects would be on collsion detection and the like though. If there will be any syncing with music it would be a futher concern. I also hope that you add vsync controls for running projects. It is true video drivers can force vsync on or off but the default is 'application specific' leaving the control to the application.
-
Im curious how you might handle this in sgdk2. I consider the fact that game time is directly connected to FPS to be a disadvantage in 1.4.x. There is a frame limiter but it conflicts with vsync which will cause a nasty jitter if they don't match or if the frame limit isnt diviable, ex: 30 fps 60hz vsync. If a project ran slow frame skipping could be imployed to keep game time consistant as well as making sure the gaming experiene was roughly the same for all users. I don't know what frame skipping effects would be on collsion detection and the like though. If there will be any syncing with music it would be a futher concern. I also hope that you add vsync controls for running projects. It is true video drivers can force vsync on or off but the default is 'application specific' leaving the control to the application.
The reason I have resisted moving to time-based movement rather than a frame-based movement is because I want the engine to be deterministic. I want the same set of inputs to produce the same output. This makes it possible to record a sequence of action within a game and play it back knowing that it will behave exactly the same on any computer. Also, on a related concern, I don't want it to be possible (for example) to jump a couple pixels higher on some computers just because they had time to calculate the extra frame at the top of a jump. Am I misunderstanding the technique here or is this a valid concern?
However, it's possible that SGDK2 might just be flexible enough to support both depending on how you customize your game. I'm not sure if that's the case yet, but I'm certainly approaching that degree of flexibility in what I'm planning so far.
Time based movement isn't necessarily any less deterministic than frame based movement. You just have to implement the various pieces correctly and design it so that things are consistent for inputs and events at particular times.
As this ties a bit into rendering and the fact you are using dx9/d3d I'd like to know if control of the render/blitting will be made avaible as far as linear (blur) or nearest ( blocky) and if the games intended resolution can be overidden by such. It is of particular importance for LCD's but in general as well. Game system emulators have to deal with some of this so perhaps lookinto into something like VBA http://vba.ngemu.com/ would be useful. Something that would be neat is the inclusion of visual filters that run independantly of the game/project in question. A resolution doubler, fake scan lines, fake lcd, motion blurr, etc. If you could invoke different filters per project that would be a plus too but I dont know how feasbile this would be. Motion bluring would rock though =]
I wasn't planning on doing this myself, but I was talking to a skilled developer a couple months ago (I think it was Kevin Gadd aka "Hiretsukan" (http://www.luminance.org/ (http://www.luminance.org/))). But he showed me a demo he had with dynamic lighting on 2-D sprites/tiles based on Direct3D. We talked about him maybe working on some similar effects for SGDK2, but were waiting for SourceForge to release their new version control system (which I think comes out at the end of this month) before uploading all the SGDK2 code and maybe splitting the work. Cool, I don't think I've been to his web site until just now -- looks like he's done quite a bit of work with game engines (same age as durnurd too).
Real motion blurring would require a lot more than a filter - you'd have to render multiple seperate frames for every displayed frame, which means that if you wanted to display motion blurred gameplay at 30fps, you'd need to render at 60fps for 2x motion blur, or 120fps for 4x motion blur. And the game would need to update at that rate as well. (This is a good reason to go for time-based movement and processing, because it allows you to render more frames than you update and still get reasonable accuracy.)
Other filters like resolution scaling and scanlines are pretty straightforward, though. Draw the game screen to an offscreen render target, and draw that render target to the screen while applying a shader to perform the effect.
Render effects
I'm hoping that there will be some tools for lighting and other effects. SGDK2 will be dx9 and its pretty much the norm for modern 2d games. example: If I'm iin the dark but have a glow around the player to see what is immediatly infront of me or there is an explosion/ etc producting light. The level editor could drop various styles of lights like droping a path on a map, be it fixed, moving or in relation to a sprite/object. Particle effects for exploisions, weapons, etc could be scriptable.
With translucany I can do a lot of things like shadow maps via tiles but dynamic lighting will be more tricky depending. Basiclly I'm lookin for coded effects where producing them from a png/file is not the best option. This could be considerd for transition effects, fading or flashing a screen to a color etc as well. I suppose I am invisioning a gfx scripting engine for effects plus light droppin on map. Feel free to tell me I'm out of my gord for the request =P
I haven't looked into what kinds of things Direct3D can do. Hopefully we can get Kevin in here to talk about what might be possible.
Given access to render targets and multitexturing, you can pull off a lot of cool things. Lighting's fairly simple. Access to pixel and vertex shaders makes it easier and lets you do a lot of really interesting things - convolution filters (blur/sharpen/emboss/etc), deformation mapping, etc.
Fairly simple, unfortunately, doesn't necessarily mean easy to design, implement, or test. But it's definitely doable. (The performance you'll get out of it is another matter, but generally speaking it should be more than playable on a modern 3D card.)
-
Time based movement isn't necessarily any less deterministic than frame based movement. You just have to implement the various pieces correctly and design it so that things are consistent for inputs and events at particular times.
I don't see how that's possible. In a time-based movement system, the pixel a sprite ends up at in any particular frame is, to some extent, dependent on time (I believe that's the definition of time-based movement). That means a sprite can be at different locations on different-speed computers. That means the system is non-deterministic, because time is an unpredictable input. There may be ways to work around the system's non-deterministic-ness (non-determinism?), but I don't see how it can be turned into something deterministic and still be time-based. The only ways I can think of to make it deterministic starts going back toward frame-based motion -- for example poll the input and process game logic at fixed intervals, then just draw as many frames as possible between these fixed intervals while only processing sprite velocities and positions -- not doing any collision detection or anything. I'd consider that time-based rendering with frame-based movement (not even sure if that's possible). Is that what we're after?
-
I don't see how that's possible. In a time-based movement system, the pixel a sprite ends up at in any particular frame is, to some extent, dependent on time (I believe that's the definition of time-based movement). That means a sprite can be at different locations on different-speed computers. That means the system is non-deterministic, because time is an unpredictable input. There may be ways to work around the system's non-deterministic-ness (non-determinism?), but I don't see how it can be turned into something deterministic and still be time-based. The only ways I can think of to make it deterministic starts going back toward frame-based motion -- for example poll the input and process game logic at fixed intervals, then just draw as many frames as possible between these fixed intervals while only processing sprite velocities and positions -- not doing any collision detection or anything. I'd consider that time-based rendering with frame-based movement (not even sure if that's possible). Is that what we're after?
Time is consistent no matter what computer you use, unlike framerate. Therefore, time-based movement would be entirely consistent between machines, while frame-based movement is only consistent if you guarantee a consistent framerate.
In time-based movement, you basically would 'update' certain things in a frame-based way, in that they are updated N times a second in discrete steps. Things like movement and linear animation, however, aren't actually done in discrete steps so you can 'update' them in one huge chunk by determining the amount of elapsed time since the last update and applying changes appropriately.
Generally speaking, this is how time-based processing is done in most games. Some crazy AI systems can update in a time-based manner as well using some sort of complex mathematical abstractions I don't entirely understand, but generally speaking things like AI and pathfinding are frame-based (done in increments) while animation, collision detection/response, and movement can be done in huge steps based on elapsed time.
-
Hmm... I have a feeling this isn't going to be resolved quickly with abstract descriptions. But I'm up for one more round. I still get the feeling that time-based movement is non-deterministic compared to frame-based updates because the computer can control exactly how much it does within each frame, but it can't predict how much will get done within a certain timespan. So the amount that gets done on different machines will be different, causing the game to play differently on faster machines versus slower machines (I guess that's the whole point -- you get a better experience on a faster machine). But that also means that repeatability of the exact same sequence is difficult to implement at best (and impossible at worst).
-
Hmm... I have a feeling this isn't going to be resolved quickly with abstract descriptions. But I'm up for one more round. I still get the feeling that time-based movement is non-deterministic compared to frame-based updates because the computer can control exactly how much it does within each frame, but it can't predict how much will get done within a certain timespan. So the amount that gets done on different machines will be different, causing the game to play differently on faster machines versus slower machines (I guess that's the whole point -- you get a better experience on a faster machine). But that also means that repeatability of the exact same sequence is difficult to implement at best (and impossible at worst).
Here's an example:
Update @ 0.00 seconds (no movement)
Left pressed @ 0.50 seconds
Update @ 1.00 seconds (distance_moved = 0.5) (movement: X -= distance_moved * velocity)
Left released @ 1.25 seconds
Update @ 2.00 seconds (distance_moved = 0.25) (movement: X -= distance_moved * velocity)
Provided that you do the appropriate processing when events (like key presses) occur instead of waiting for the next update, you can get almost exactly the same results every time you run it, even if you vary the update rate. (Of course, rounding errors and floating point accuracy can be a problem, but that's pretty manageable). You just have to handle timing properly everywhere. For things like AI that need to be processed X times a second, you can either update them in chunks or run them in a background thread. However, you will lose complete repeatability there, since there's no real way to execute more code per second than your system is capable of executing. So if you reach the point where your system is just too slow to run the AI in realtime, the system won't be able to maintain correct behavior. But if your system is fast enough to run at 120FPS, you can get totally smooth updating at 120fps without needing to run your AI at 120fps (useful for rendering subframes for doing motion blur, for example), and if your AI only needs to run at 15fps, you can run at 30fps or 60fps and still get the same behavior (even if the framerates are different).
You can approximate this to some extent with a good frameskipping algorithm, but time-based processing is more efficient than frameskipping if done properly, which is definitely desirable if you're aiming to make your game run good on low-end systems (since they're definitely going to be skipping frames.)
-
I'll attempt to shed some light on this subject. Essentially time based movement is supposed to keep movement consistant reguardless of actual frame rate. It is essentially based on elapsed time between calls, so that if you have a slow computer the object will appear to move at aproximately the same rate as it does on a fast computer. Let's say you need to move a spaceship from star A to star B, and let's say they're aproximately 50 pixels away from each other. On a slower computer (hypothetical) the spaceship might move 5 pixels per second, on a faster computer it may move 10 pixels per second. At 5 pixels per second 50 pixels would take 10 seconds, at 10 pixels per second 50 pixels would take 5 seconds. But here's the problem, the speed isn't the same, the slow computer takes 10 seconds whereas the faster one takes only 5. So how do you account for that? Time based movement. You call a timing function (usually with millisecond resolution), Save the start time and the end time, and subtract the start time from the end time, to get the actual amount of time elapsed. You then use it to input into your movement. Essentially you adjust the pixels the ship moves per step based on how long it's taken since the last call to get_time. What it results in, is that now, the slow computer will move the ship 10 pixels per second, resulting in the 5 second move, which is exactly what the faster computer does. (Ie the slower ship moves farther in the step than the faster one does). The only major problem with this is that with a really slow computer the frame-rate gets a little jerky, because it apears to jump farther to stay in sync with what a faster computer would do.
Frame based movement of course relies on how fast the computer can update frames. This is why you have some older games that move unplayably fast on more modern computers, and at a correct speed on slower computers. Newer games that use this method essentially rely on the speed the video can update, which means a slow computer on a modern game appears to make the game move "in slow motion" because it can't update fast enough.
So really it's a tradeoff. If you can guarantee at least x amount of frames per second on slower computers, then it shouldn't be a problem, because usually you frame-limit games so they don't go too fast on new computers. (Say 30-60 fps depending on what you're doing). Time based movement on the other hand requires that the computer be fast enough for the game to feel smooth.
I hope this clears up what you're trying to talk about.
Keith
-
Well, that pretty much describes what I already knew about time-based movement. So now let me describe another example of a problem that it presents. Consider a sprite standing on a cliff looking accross to the right at a wall on the other side. In the wall (a ways below) is a narrow passageway that the sprite can duck into if he presses toward it while falling down against the wall. Lets say the sprite is 50 pixels high and the passageway is 52 pixels high and the top of the passageway is a y coordinate of 100. The sprite jumps to the other side and begins his fall at a y coordinate of 95.
Here's how the frames work out in a time-based movement system:
Fast computer:
Frame 1 y =95 Time = 0.0 sec
Frame 2 y =96 Time = 0.25 sec
Frame 3 y =98 Time = 0.5 sec
Frame 4 y =101 Time = 0.75 sec
Slow computer:
Frame 1 y = 95 Time = 0.0 sec
Frame 2 y = 98 Time = 0.5 sec
Frame 3 y = 105 Time = 1 sec
Frame 4 y = 116 Time = 1.5 sec
Now on the fast computer, when the sprite hits 101 pixels it can fit into the passageway because it has one pixel of space both above ane below and nothing stops it from moving to the right.
On the slow computer, the sprite skips from 98 pixels (where there are to more pixels of solid wall in its way) to 105 pixels (where there are 3 pixels of solid wall from the other side in the way) so it never makes it into the passageway.
This is based on the exact same input but you get completely different results depending on whether you're playing on a fast computer or a slow computer.
The answer to this might be that I should perform collision detection for every pixel along the path instead of only once at each frame. But now you see why time-based movement starts to be slower than frame-based movement if I want repeatibility.
-
Well, that pretty much describes what I already knew about time-based movement. So now let me describe another example of a problem that it presents. Consider a sprite standing on a cliff looking accross to the right at a wall on the other side. In the wall (a ways below) is a narrow passageway that the sprite can duck into if he presses toward it while falling down against the wall. Lets say the sprite is 50 pixels high and the passageway is 52 pixels high and the top of the passageway is a y coordinate of 100. The sprite jumps to the other side and begins his fall at a y coordinate of 95.
Here's how the frames work out in a time-based movement system:
Fast computer:
Frame 1 y =95 Time = 0.0 sec
Frame 2 y =96 Time = 0.25 sec
Frame 3 y =98 Time = 0.5 sec
Frame 4 y =101 Time = 0.75 sec
Slow computer:
Frame 1 y = 95 Time = 0.0 sec
Frame 2 y = 98 Time = 0.5 sec
Frame 3 y = 105 Time = 1 sec
Frame 4 y = 116 Time = 1.5 sec
Now on the fast computer, when the sprite hits 101 pixels it can fit into the passageway because it has one pixel of space both above ane below and nothing stops it from moving to the right.
On the slow computer, the sprite skips from 98 pixels (where there are to more pixels of solid wall in its way) to 105 pixels (where there are 3 pixels of solid wall from the other side in the way) so it never makes it into the passageway.
This is based on the exact same input but you get completely different results depending on whether you're playing on a fast computer or a slow computer.
The answer to this might be that I should perform collision detection for every pixel along the path instead of only once at each frame. But now you see why time-based movement starts to be slower than frame-based movement if I want repeatibility.
Your problem there is that you're basing collision detection on pixels and increments instead of vectors. :P I guess there might be some design reasons for this, but generally speaking you're better off using vectors since the collision detection breaks down into some simple equations instead of requiring a bunch of expensive checks every frame. (And as a bonus, it's much easier to get it to work correctly in situations like the one you're describing.)
Using vectors for collision detection also gives you the bonus of not requiring the player to be so exact in positioning a sprite to fit through a narrow passageway, since you can more easily do things like making a sprite slide across a surface in a convincing manner and determining whether or not it can fit.
In general, if you *do* want to use time-based movement, you want to avoid algorithms that must be processed in set increments (like pixel-based collision detection). Trying to mix the two does result in bad framerates, for the reasons you've noted.
-
Yeah, vectors heh. I implemented a decent collision system that accounted for falling into a tile, however, not for going through tiles or sprites. That would have been the next thing I learned about collisions. But usually it's something like drawing a line and then testing if the line intersects the tile(s) at any point. And by lines I mean mathematical lines, not actually drawing lines on the screen.
That's the theory at least. I mean obviously a line is a simple case of a vector (or what I understand of vectors)
Keith
-
So I think that's the problem. Even if I were prepared to re-invent my understanding of collision detection with the map, I think I'm still going to want to be able to support pixel-based collision detection between sprites, which presents similar problems. Time-based movement may be OK for specific games, but I fear that trying to incorporate it into a general-purpose engine might present problems and/or might make the kit significantly harder to use. I don't want to dismiss an important feature lightly, but I really am ... "terrified"? This is such a funtamental feature that it would affect almost every aspect of the engine, and if I find a problem somewhere down the line, I may have to start all over or completely give up. I'm not prepared to take such a risk when I have in mind something that I know I have been able to work out in the past in a way that's reasonably user-friendly for a general purpose 2D game creator. One of the things that makes me nervous is a piece of frame-based tile collision code that I've been carrying along from various projects and slowly enhancing and mutating for the past 15 or so years. I can't imagine having to re-develop and test that from scratch :o.
Don't get me wrong, I'm not afraid to try new technologies and I may someday make a game with time-based movement or might even figure out a way to incorporate time-based movement support into SGDK2 if it turns out not to be as fundamental as it feels (maybe I can design specific "sprite rules" that are time-based instead of frame-based). But the only reason I am able to make an engine like this on my own is because I have thoroughly understood and worked with practically every technology I'm dealing with before and am comfortable with it. If I wanted to trust myself with incorporating time-based movement into a project like this, I think I would have to start small.
-
I'd say try to find the benefits. Perfect collision detection, and a game that runs the same on almost every system. (In other words you don't get the slow down from too many sprites on screen in some frames, and in others were it speeds back up. Instead it gets jerky but every position is updated to the right position based on how much time it takes).
Most all the games you play nowadays use some form of time based movement. (In some 3d cases there's an even different technology called rendertweening for 3d, essentially it uses the time and then generates the inbetween poses so you're assured of the smoothest movement possible on your system, but that is way more advanced)
In any case, i'm not going to change your mind. In fact I found out that anything you suggest to anyone is just not going to take. Because unless it's their idea, they don't really care much what you think. Even in cases when someone asks you for your opinion they've already made up their mind. They just want some validation even if you choose the opposite idea from theirs.
I personally go by the 2-3 rule, if 2 or 3 or more people suggest something, then I start listening, otherwise I don't worry about it. And we're only 2 people... but I wasn't even trying to convince you to do it, i'm just saying that the problems you're naming are mostly an excuse for the fact you don't want to implement it. And that's fine by me. No one else has made a nice system like you have here, and until there's a better system i'm sticking to it.
Keith
-
Well, another problem with time-based movement is that if it's running on a low-end computer, and it gets jerky, then suddenly you have no idea where your player sprite is, and you may have walked too far and fallen off a ledge and DIED. with Frame-based movement, there's no chance of that.
-
Losing track of sprites & falling off a ledge... this is at what, 5 fps? At 5 fps its gonna suck either way. At 15-20 fps time based would be somewhat jerky but playble vs less then one 3rd the speed the intended speed. Its an easy choice for which I'd rather play.
In a fast paced arcade style game, timing is everything. Someone with a slow machine has a huge unfair advantage. That is if they are even willin to sit through the slow experience. Many people wouldn't notice that a game is running half framerate in time based but no one could miss the fact with all frames rendered it running half the intended speed. Technical issues aside time based makes the most sense for peserving playabilty (as well as the game designer intentions) on low end systems.
-
Note I already mentioned the "jerky" problem. And OPX is right, unless it's really really slow, it doesn't become at all unplayable. It's just annoying when you're playing a game and it's moving nice and fast, and then suddenly chugs because there's one-too-many sprites on the screen. I'd much prefer a completely playable but slightly jerky experience.
Again, Mr. Marty, don't assume i'm trying to convince you, i'm just saying.
Keith
-
As a side note, I've noticed that the "one-too-many" mark is around 250 sprites on my system. (And it's not sprites on the screen, it's sprites active in the map).
-
In any case, i'm not going to change your mind.
-
Naturally you have to weigh the validity of incoming ideas & suggestions... considering the pros, cons, impact, feasibility and how they incorporate. Whether or not you choose to use or dismiss an idea/suggestion in the end is up to you. It also remains my right to bitch about it :P
Just as there are dangers of incorporating foreign concepts and ideas there are dangers in limiting yourself only to what you know and/or your own thought process. On a project of this size and scope there are undoubtedly things that haven't been considered. Many of these are easy additions. Some require a minor rethinking or retooling in 1 particular aspect. Others may require extensive rethinking or in fact challenge the overall nature of the beast. That doesn't have to be a bad thing though I can understand reluctance and risks it poses. It certainly doesn't make sense to recklessly make major changes without a full understanding the process, consider the implications and testing it (thats what demos are for). As the project is still in its infancy (yes?) now is the time for such ideas to come forth. Again, whether they are included in the final product or not is up to you. In the end you have your own goals and ideas to give form. So... What are your goals with SGDK 2?
I only skimmed your post before I wrote the above. After re-reading I realized I restated a few things in my own words. You are concerned about the game behavior being consistent across all systems and rightfully so. With that in mind surely you also see how the speed of the game effects the experience. I consider it an extension of the first. Whatever your reasons you can't avoid acknowledging the above statement and my previous post/response to your brother on the matter ;D
Perhaps time based does present too many problems, but I still think looking into and maybe some demos are worth a try. Anyway... I image there are alternatives to get at least some of the benefit. For instance, a speed slider that reinterpreted the values in the project so everything is still frame based but the game uses more or less frames to get the job done. If everything is adjusted together it shouldn't effect game mechanics eh? I imagine that could cause some problems with scripts an such but if its built in then it would be taken into account when scripting. Would that be a frame skipping algorithm? It could be done manual (control is nice) and/or automatic which may represent problems. This would also help someone who is designing on an under spec system.
Collision detection came up but this may be yet another deviation from topic. Pixel collision is nice but what do you plan to do with alpha channel values? Also I may not want pixel collision to match the sprite's visible form. So that means utilizing a pixel collision masks (separate image) or vector based collision. If vector based an algorithm to match/trace the pixel outline could be used in less redefined making it transparent to the novice while giving more control to the experienced user...
Any intentions of mutliplayer code first or 3rd party? A pixel collision mask is problematic for mutliplayer (cheating, but sumcheck could help). Again game speed would come into play as they have it have to be synchronized across multiple machines, in less its turn based only. I had a demo for some mutliplayer function in 1.4 yea? So obviously it's something you have considered to some extent.
Just as you have thought about SGDK 2 for years so have I. Sure I'm no programmer and my Ideas aren't necessarily polished.... many are more
-
OK, this is slowly getting back on-topic so I'll just leave everything where it is.
In the end you have your own goals and ideas to give form. So... What are your goals with SGDK 2?
I think, basically, I want to fix all the fundamental flaws and shortcomings in GameDev 1.x that I have known how to fix all this time, but couldn't accomplish under the old architecture: the graphics editor was a big piece (glad I'm done with that part for SGDK2). The way sprite templates and definitions are defined was probably the next biggest thing. In watching a presentation at a local IGDA meeting about a fighter engine someone had created, I realized that it would be possible to define sprites in terms of a set of states and how you switch between them instead of hard-coded templates. And of course I also want to get past that big obstacle of having to re-create your templates/definitions on every map. The next thing was taking advantage of .NET's reflection and run-time code compilation abilities. Those were the primary goals, I think -- pretty specific. Of course I do want to take the opportunity to improve anything else that I can in the process of rethinking the whole thing from the ground up.
I only skimmed your post before I wrote the above. After re-reading I realized I
-
In the shower this morning (that's the best time and place for thinking isn't it?) a thought occurred to me. I should be pre-processing the tile shapes to give me instantaneous access to some useful information like:
1. "What's the topmost solid pixel between (inclusive) columns X1 and X2 in this tile?"
2. "What's the bottommost solid pixel between columns X1 and X2 in this tile?"
3. "What's the leftmost solid pixel between rows Y1 and Y2 in this tile?"
4. "What's the rightmost solid pixel between rows Y1 and Y2 in this tile?"
Let's see, how many numbers would that be?
I think it'd be W*(W+1) + H*(H + 1) where W and H are width and height of the tile shape
so for a tile shape applied to an 4x3 tile, let's see if that works out
1. X=0 top
2. X=0-1 top
3. X=0-2 top
4. X=0-3 top
5. X=1 top
6. X=1-2 top
7. X=1-3 top
8. X=2 top
9. X=2-3 top
10. X=3 top
11-20. same for bottom
21. Y=0 left
22. Y=0-1 left
23. Y=0-2 left
24. Y=1 left
25. Y=1-2 left
26. Y=2 left
27-32. same for right
32 = 4*5 + 3*4
Yep. So for a tile shape being applied to a 32x32 tile, how many numbers would that be?
32*33 + 32*33 = 2112.
So assuming there's 10 tile shapes that only need to be calculated at one size, that'd be 21120 numbers, which, if stored as 2-byte integers, would be 42240 bytes (~42K). That's not too bad. And if I have that information I think I can drastically improve some of my map collision detection -- both the performance and the quality. It might make it more suitable for time-base collision detection too. But I'm still not sure if I will be able to effectively answer the question "Are there any solid pixels between the rectangle at (x1,y1,x2,y2) and the rectangle at (x3,y3,x4,y4)?" which is really what I need to answer effectively for time-base collisons. Regardless of how much this design helps time-based collision, I think it's helpful for other reasons, so I'll start down that path when I get to it, and if it helps, it helps.
I can't believe I was searching for these pixels one pixel at a time before in real time. It made the function so complicated and probably slow. I think this will help solve the issue of sprites only checking their corners for collidions with solidity. Now I can almost immediately know what the highest pixel between a sprite's lower left corner and its lower right corner is, and I can search one tile at a time instead of one pixel at a time, which will solve the problem of what happened when a sprite is larger than a tile.
-
This is a late reply however a point of concern...
okay, what if I wanted my character to follow slopes(tilt)? From the SGDK2 demos I gather there is rotation of tiles but what about realtime rotation of sprites? I would think rotating the collision box would come into play but maybe not.
Otherwise geometry based sounds good to me, considering I can controll the size of the collsion area to the sprite. Usually per pixel collsion isnt noticable. If the area is sizable & independant of the sprite hills should no longer preset an issue (walking on air).
There are still many related issues to bring up.. mostly combination of collision detection,vector data and phyisics model. Tethered objects, birdges that bow with the player on them, etc.
-
I wasn't planning on getting sophisticated enough to rotate solidity, at least not for tiles. The idea would be, each tile on the map, even if it's doing real-time rotation to draw its graphics, will still have a set solidity function that will be pre-processed for optimal performance. Each tile will still be associated with some pre-defined shape (now you can make your own shapes, though). And when sprites are interacting with the map, they will just have square solidity regions (similar to GameDev 1.x) but now you will be able to make that
region smaller than the sprite graphic and offset it so it's not in the top-left corner. (This is accomplished by properly defining the frameset transformations for the frames that compose the sprite, and then defining the width and height of the sprite solidity when creating a new sprite state.)
As far as sprite collisions with other sprites, you have a valid concern. I haven't solidified the design of how sprite collisions with other sprites will work yet. However, you should know that my real-time rotation support will all be based on frameset frames that define the transformation. I'm not currently planning to intrinsically support the ability to define an arbitrary rotation at runtime. If you want to draw a sprite at a particular rotation, I'm thinking that you will have to define a frame (in a frameset) that rotates a graphic cell to a particular rotation value, then reference that frame from the sprite state. I hope this is acceptable. There should eventually be wizards to automatically help generate these rotations etc. Yes, that still means you have to define all your rotations ahead of time, but the advantage is that you don't need to store the rotated versions, and then you can define the properties of each rotation separately (define a different bounding/solidity box). I'm not planning on supporting bounding boxes that don't align with the X and Y axes. But I might support pixel-based collision masks, which I would have to pre-calculate for every frame of every sprite (alpha > 127 = solid, alpha <=127 = empty?). That means each rotated frame would have its own pre-calculated collision mask, stored simply as an array of bits, which should work much faster than my collision detection in GameDev 1.x. Not sure if I'll take that on in this release.
Some of this isn't set in stone either, though. I think the code is open-ended enough that you could relatively easily implement a user-defined property on a sprite that determines its rotation, and change the common sprite code (which is saved as part of the project so you don't have to work with a customized version of SGDK2 to do this!) to process that user-defined property as a rotation that should be applied before drawing (just change the Draw function that draws the sprite). Of course that still leaves the exercise of the bounding box to the reader. But at least some of the flexibility is there.
-
Oh, I neglected to mention (again?) that time-based movement may require that I throw out support for pixel-based collision detection. I might put out a call for help if and when I decide to intrinsically support pure/true time-based movement. Otherwise, I might build in frame-based movement and leave time-based movement up to SGDK2 customizers (I think you might be surprised as how customizable SGDK2 will be... could maybe even create a project template that would support some real hardware-accelerated 3D). I have hard time getting my mind around what will be possible with the level of flexibility that will be availble in SGDK2 (even without modifyiing the SGDK2 source code -- just defining a project). But I hope, now, that it can leave a lot of the harder questions for later so that I can get something simple and functional out, without sacrificing extensibility for the nice new features in the future.