Author Topic: Game clock vs. fps + rendering options & effects  (Read 9908 times)

Uhfgood

  • Regular
  • **
  • Posts: 26
    • AOL Instant Messenger - Uhfgood
    • View Profile
    • Indie Flux
Re: Game clock vs. fps + rendering options & effects
« Reply #15 on: 2006-02-09, 10:24:15 PM »
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

Keith Weatherby II
http://www.gamesafoot.com
Uhfgood -at- verizon -dot- net

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: Game clock vs. fps + rendering options & effects
« Reply #16 on: 2006-02-09, 10:33:42 PM »
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).
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Game clock vs. fps + rendering options & effects
« Reply #17 on: 2006-02-10, 07:42:25 AM »
In any case, i'm not going to change your mind.

Orion Pax

  • Contributor
  • Regular
  • **
  • Posts: 38
    • View Profile
    • OPX
Re: Game clock vs. fps + rendering options & effects
« Reply #18 on: 2006-02-10, 07:04:20 PM »
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

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Game clock vs. fps + rendering options & effects
« Reply #19 on: 2006-02-11, 09:56:04 AM »
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

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Game clock vs. fps + rendering options & effects
« Reply #20 on: 2006-02-12, 09:16:06 AM »
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.

Orion Pax

  • Contributor
  • Regular
  • **
  • Posts: 38
    • View Profile
    • OPX
Re: Game clock vs. fps + rendering options & effects
« Reply #21 on: 2006-03-31, 08:16:08 AM »
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.

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Game clock vs. fps + rendering options & effects
« Reply #22 on: 2006-04-02, 08:46:10 PM »
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.

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: Game clock vs. fps + rendering options & effects
« Reply #23 on: 2006-04-02, 08:53:43 PM »
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.