Flare - 60fps
Flare - 60fps
I love playing games with high frame rates. :) When I played Flare it bugged me that raising the frames_per_second in the config file caused everything to run faster. I thought it would be cool to have the game run at the same speed regardless of FPS so I started writing a patch for it. Unfortunately I had to make a lot of changes in order for things to work properly. So much of the game was entirely dependent on a fixed frame rate.
Anyway, as I was working on this I was practically forced to add some new features to make the system robust enough. So I added some new concepts such as Triggers. Triggers are a combination of Conditions and Actions. When all the Trigger's Conditions are met the Trigger's Actions are executed.
I might have missed some stuff but I think all of the events in the game should "scale with the frame rate" now. This results in worse overall performance (i.e. more CPU consumption) even though the game feels like it's running better if your computer can handle it and you are playing at more than 30fps. I have lots of ideas and plans on how to reduce the performance impact considerably though.
I also want to make the code more generic. Currently I have a few abstract classes and lots of derived classed but I think many of the derived classes could be eliminated somehow. I'll look into it.
All changes are based on version 0.13 of the game. The patch file is attached.
Let me know if it works for you and just ask if you have any questions.
I'm taking a look at the code now.
Can you explain the need for this trigger and action system? How does it relate to framerate?
Well, the old code would link actions (such as a melee attack) to a specific frame of an animation. Because frames were updated sequentially we could be sure no frame and no actions were missed. Now if we want things time based we run into some problems. Here is an example:
Our attack animation has four frames which last 100 ms each. If we call logic() at 88 ticks that results in displaying the first frame of the animation. If we call it again at 213 ticks we have reached the third frame and essentially skipped one frame. If we have an action linked to the second frame then that never takes place.
So my first thought to solving this problem was to simply check whether we have passed the second frame (>= as opposed to ==). But then we also have to keep track of whether we have performed the action or else the character will attack again on the fourth frame and so on. But as well as remembering that we've performed the action we also have to re-enable performing it at some point or else we only get one attack in the whole game. :D So I thought we could simply disable an action after it's been performed for a certain amount of time. It just made sense to introduce a new class for that and it sort of evolved into the concept of Triggers.
Does that make any sense? ^^
It makes sense. I agree with the reason, but the implementation is a bit sprawling.
Much of the excitement over Flare is with portable linux gaming devices, where performance is a major concern. I'm not sure if changing the game to 60fps adds enough to alienate this group.
I like the idea of making all animations ms-based instead of frame-based. I want to revisit this later. Please hold off on new code on this for now; I'll get in contact with you on a later version when I'm thinking about making this change.
Yeah, I see what you mean. I'll continue playing with this for a bit and try to optimise things but I understand if you don't want to make use of this code in the engine.
>Much of the excitement over Flare is with portable linux gaming devices, where performance is a major concern. I'm not sure if changing the game to 60fps adds enough to alienate this group.
Should't you switch to OpenGL then? I doubt that those portable devices have enough CPU power to software render with SDL. *stillpickingonthat*
True, OpenGL is definitely something you should focus on for smooth performance on a portable device.
Spell Said: I doubt that those portable devices have enough CPU power to software render with SDL.
I think another question would be, at the time they have enough CPU power, (and that time will come), would they also support OpenGL. I think they would be foolish not to support it.
I have also had a thought about OpenGL
Some advantages of OpenGL are
Some advantages of SDL are
So, in my opinion OpenGL will be an improvement, but one that will take some time to implement. Also, I am sure FLARE should eventually work with OpenGL.
> Increased frame-rate (Somewhere I read, double or tripple, but it should be checked)
Usually it's a lot more than double or tripple, atleast if you know the pitfalls of OpenGL. My 2d game engine currently runs at about 1700 FPS (some years old PC) and there is still a lot room for optimization.
> Requirement to rewrite whole parts of code. I expect this will take two weeks or so. For textures http://lonesock.net/soil.html might help.
For loading images he can still use SDL. There is no problem with using SDL for anything but graphics. Two weeks isn't much regarding clint is making FLARE as a long term project. Better implement it early than late.
>Many Hand-held devices support SDL but not yet OpenGL
I really really doubt that. OpenGL is an industry standard which is implemented everywhere where GPU acclerated graphics are neccesary (every newer device which wants to be able run games, exception are the Nintendo devices as they always use their own propritary technologies). SDL on the opposite is just an independant library which claims to be crossplatform.
I'd prefer using OpenGL abstracted. I think SDL 1.3 is supposed to have 2D blitting wrapped around OpenGL. Maybe SFML does the same?
Either way I'm not going to make the switch yet. The game is enjoyable as is.
Most likely scenario: when I decide the game absolutely must have dynamic lighting, I'll have to move to OpenGL then.