Writing a better 2D engine. (Phoenix 2D Game Engine)

[cairnswm]

I prefer being in control of my own gameloop and timing. I'd suggest finding a nice way of managing user input is more important

I havn't spent time on this for a while but I will do so again soon. I just have a few deadline for the end of the month I'm trying to get done - and for once playing games is taking tooo much time away from development (I'm playing Zeus and DiabloII a lot at the moment).

[jdarling]

One comment more i have is that your TLUA class contains both the wm and the script source in one class, would love to se an seperation there, meaning that you can run multiple scripts in the same wm, thus you have a shared vm where you can run a list of precompiled scripts or functions in thoose scripts.

What does WM stand for?

I'm not a expert of lua myself but as far as i have understod yuu can have many instances of the luaVM actictive and every instance of it has its own set of global variables that can be shared between many scripts, wich would be a nice thing to have easy access to.

Well, I'm no expert, but I'm quickly becomming one. Very quickly in fact .

The whole idea behind this is that the user shouldnt need to call any core lua functions if he doesn't wants to, ie he dont need to know anything about the lua interface to be able to include his scripts and functions in a easy way.

Completely agree, see the rest of my comments below

I will add special functions for word wrapping and text formatting

The next part of the engine is probably to convert the glxtreeem gui engine, (have prewritten gui editor so will save alot of time) but with some changes, if you have any suggestions for it please post em here.

I have sample code for both of these that I use in JumpStart. Its written to work on a generic TCanvas so it should be easily ported. I'll admit though that it isn't pretty nor perfect, and not even close to optimized . But it works

Then we have to deside how to work with game loops and timers, anyone has any good ideas on good solutions ?

Two thoughts; One we distro a compiled version that basically requires the user to write scripts to build there game. Most of what I've written up for JumpStart is completely portable (editors for game worlds and etc...). Two we also have the source available so that more advanced persons can download and build there own wrapper exe as they see fit. Many people won't agree on how game timers and control loops should be implemented. I like state machines for primary control and up front loading for speed. Others will say I'm nuts.

On the subjects about the scripting wrappers. Since DWS, Pascal Script for Delphi, and all of the others are written in Delphi for Delphi they can have some very nice features. Lua is not, and thus some of the nice features just simply can't be implemented without loss of speed or ALOT of effort. I'm not willing to give up speed, and I don't have alot of time.

So my solution is the pas2gen application. Basically it reads a given pascal file and generates a wrapper for your scripting engine. First engine out the door will be Lua (and this is almost complete, god willing and the creeks don't rise, by July 5th). I've spent alot of time on making the application as easy to use as possiable, but it still has its difficulties.

I think that you will find that if we do a good enough job, more Lua people will use the engine then Pascal/Delphi users. Simply put; more people know and use Lua right now then Pascal/Delphi. Its in most of the big games, and people love to mod. At least I'm surprised at the numbers using JumpStart (and its not even alpha release ready).

The largest problem we are going to have (as I see it) with the scripting engine right now is events. They arn't going to be easy. In fact they are going to be quite the pain. I've been working on this problem for quite some time. Hopefully soon I'll have a good working solution (instead of a poor working one, witch I currently have).

On the subject of multiple VM's. Yes you can have multiple VM's loaded at the same time. They do not play well together. They don't know about each other, they don't share process space, and forcing them to do so causes bad things to happen. JumpStart initially had all of these problems. Now I'm moving up to using Co-routines, basically VM based threading. This works quite well. We can run scripts seperately that don't need to know aobut each other. For example the debug console control script will be completley seperate from the game script. Unfortunately the actuall processing of the commands must be in the game script .

Course all of this is once we get to an multithreaded environment. First it will all be single threaded, I have to walk before I can run, and personally I'd rather see the entire engine stable in single thread mode then migrated to multi-threaded.

[Andreaz]

I prefer being in control of my own gameloop and timing. I'd suggest finding a nice way of managing user input is more important

Yeah, controll is good, gonna try some different approaches, maybe a wait based timer instead of callbacks... Regaring inputs, soon done, will look much like DXInput but with some added functionability to use for the gui engine and such.

I havn't spent time on this for a while but I will do so again soon. I just have a few deadline for the end of the month I'm trying to get done - and for once playing games is taking tooo much time away from development (I'm playing Zeus and DiabloII a lot at the moment).

hehe, fun to do some other stuff from time to time aswell :O

[Andreaz]

One comment more i have is that your TLUA class contains both the wm and the script source in one class, would love to se an seperation there, meaning that you can run multiple scripts in the same wm, thus you have a shared vm where you can run a list of precompiled scripts or functions in thoose scripts.

What does WM stand for?

I'm not a expert of lua myself but as far as i have understod yuu can have many instances of the luaVM actictive and every instance of it has its own set of global variables that can be shared between many scripts, wich would be a nice thing to have easy access to.

Well, I'm no expert, but I'm quickly becomming one. Very quickly in fact .

The whole idea behind this is that the user shouldnt need to call any core lua functions if he doesn't wants to, ie he dont need to know anything about the lua interface to be able to include his scripts and functions in a easy way.

Completely agree, see the rest of my comments below

I will add special functions for word wrapping and text formatting

The next part of the engine is probably to convert the glxtreeem gui engine, (have prewritten gui editor so will save alot of time) but with some changes, if you have any suggestions for it please post em here.

I have sample code for both of these that I use in JumpStart. Its written to work on a generic TCanvas so it should be easily ported. I'll admit though that it isn't pretty nor perfect, and not even close to optimized . But it works

Then we have to deside how to work with game loops and timers, anyone has any good ideas on good solutions ?

Two thoughts; One we distro a compiled version that basically requires the user to write scripts to build there game. Most of what I've written up for JumpStart is completely portable (editors for game worlds and etc...). Two we also have the source available so that more advanced persons can download and build there own wrapper exe as they see fit. Many people won't agree on how game timers and control loops should be implemented. I like state machines for primary control and up front loading for speed. Others will say I'm nuts.

On the subjects about the scripting wrappers. Since DWS, Pascal Script for Delphi, and all of the others are written in Delphi for Delphi they can have some very nice features. Lua is not, and thus some of the nice features just simply can't be implemented without loss of speed or ALOT of effort. I'm not willing to give up speed, and I don't have alot of time.

So my solution is the pas2gen application. Basically it reads a given pascal file and generates a wrapper for your scripting engine. First engine out the door will be Lua (and this is almost complete, god willing and the creeks don't rise, by July 5th). I've spent alot of time on making the application as easy to use as possiable, but it still has its difficulties.

I think that you will find that if we do a good enough job, more Lua people will use the engine then Pascal/Delphi users. Simply put; more people know and use Lua right now then Pascal/Delphi. Its in most of the big games, and people love to mod. At least I'm surprised at the numbers using JumpStart (and its not even alpha release ready).

The largest problem we are going to have (as I see it) with the scripting engine right now is events. They arn't going to be easy. In fact they are going to be quite the pain. I've been working on this problem for quite some time. Hopefully soon I'll have a good working solution (instead of a poor working one, witch I currently have).

On the subject of multiple VM's. Yes you can have multiple VM's loaded at the same time. They do not play well together. They don't know about each other, they don't share process space, and forcing them to do so causes bad things to happen. JumpStart initially had all of these problems. Now I'm moving up to using Co-routines, basically VM based threading. This works quite well. We can run scripts seperately that don't need to know aobut each other. For example the debug console control script will be completley seperate from the game script. Unfortunately the actuall processing of the commands must be in the game script .

Course all of this is once we get to an multithreaded environment. First it will all be single threaded, I have to walk before I can run, and personally I'd rather see the entire engine stable in single thread mode then migrated to multi-threaded.

Well i intended to write VM, not WM (virtual machine).

The event thing really should be quite simple, as long as you keep it as one event = one script. Ie button1.onClick='button1click.lua', and you have a list of loaded scripts in the script engine, kindof like the imagelist works.

And the idea of the framework for lua is not to make the lua coding easier but to make it easier to write own functions to be able to call from lua without needing to go trough all the hazzle with the lua api.

[wagenheimer]

How is the progress going? I´m very interested in doing multiplataform games!

Asphyre Engine (www.afterwarp.net) is a MPL OpenSource Direct3D 2D engine, with a lot of things already implemented, there are a excellent Particle Engine, a SpriteEngine very well made, and lot of more things. Maybe, some of the authors there, could help with some things in this new engine. I think the ParticleEngine and the SpriteEngine is very well, and could be upgraded and getting better for use with this new engine.

What do you think?

Sorry the bad english!
Cezar Wagenheimer

[Robert Kosek]

Wagenheimer, Yuriy had a private beta GL only version of Asphyre but wasn't impressed with it enough to use it. He has since stuck to DirectX and I doubt you'll pull him away.

It still has an excellent component base you might want to check out though.

[wagenheimer]

Humm.. Very nice... I would like to give a look! What was missing in the version that did you saw?

But, who is Yuriy? I did search here in the forum and in the afterwarp forum and did not find any Yuriu.

Thanks!

[Robert Kosek]

Lifepower := Yuriy;

And I didn't see it, it was an internal release that he did as a test. We talked about it awhile ago, not sure if you were using Asphyre then or not, but it should be somewhere in his blog I think.

But anyway, back to the topic.

[Andreaz]

Progress is going forward, having somewhat of a heatwave here in sountern sweden atm, the motivation sitting down and writing 2k rows of code after work when it's 30C in the apartment isnt that great from time to time

I'm currently wrapping up the final parts of the input management, some documentation and then a demo and public release

And cairnswm is currently working on extending the image class with additional rendering functions (unless he's playing D2 all the time ) so that's comming along quite nice.

I havn't really decided where to go next my current plan is to include the following components (not saying i will write all myself, if you feel like "wow i realy want to do that one" please reply here):

• Animation, pattern animation, multiple states (ie run, walk etc)
  Gui engine, xml based gui engine, probably texture based building of the GLXTreem gui engine.
  Sprite engine, quite straigtforward, per-pixel collisions, collision groups, a sprite format + editor
  Tile engine, higly optimized tile engine, multi layer support with different tilesize of each layer, probably 1 texture per layer for speed increase. + Editor
  Some kind of primitive renderer, lines pixels etc.
  Particle engine, xml based ? (see http://glxtreem.net/Newparticles.rar for the draft of the latest glxtreem version, alot of features)
  Sound engine, OpenAL / FMOD ?
  Resource loader, to load textures/fonts and other resources from single file resources.

But this is just a preview list, if there's anything missing or lacking please give your oppinion so this Library will own all others

[cairnswm]

Dont forget some method to do graphic transitions between game states/scenes.

When you do the Sprite engine please ensure that the X,Y coordinates work on a single/double rather than an integer to get better smoother movement.