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

[jdarling]

LOL we need an SVN to keep up with the updates . I've almost got all of the basic stuff wrapped up. Once I get the basics done I'll start adding in support for the event handlers. Only problem is that once I add them it will be very time consuming to change them, so I want to make sure that the basics are completely locked down.

PS: There was a post on GD.net about some guy making logos to help build is online portfolio. I asked for one for the project, if he comes through I'll cover the expense ($10) if you want to use it.

Also, put up the new loader code and I'll see if it makes a difference. Just the one unit would do

[Andreaz]

The new texture loader is uploaded to the homepage, not tested it fully yet through, you have to change the loading functions in the font to:

[pascal]
//------------------------------------------------------------------------------
Function LoadFontTexture(FileName: String): glUint; overload;
var Manager: TPHXTextureManager;
var W, H : Integer;
begin
Manager:= TPHXTextureManager.getInstance();
Manager.setMipmaps(True);
Manager.setFilter(tfLinear, tfLinear);

Result:= Manager.LoadTexture(FileName, W, H);
end;

//------------------------------------------------------------------------------
Function LoadFontTexture(FileName: String; Stream: TStream): glUint; overload;
var Manager: TPHXTextureManager;
var W, H : Integer;
begin
Manager:= TPHXTextureManager.getInstance();
Manager.setMipmaps(True);
Manager.setFilter(tfLinear, tfLinear);


Result:= Manager.LoadTexture(FileName, Stream, W, H);
end;
[/pascal]

And similar for the image class

[Andreaz]

Any changes with the new texture loader ? And the part about the logo is just great, much appriciated

I'm currently working on the gui engine + editor. Have converted it to a binary format though, much easier to work with and faster aswell. The editor's powerfull enough to not being able to change the gui components manually

[jdarling]

Well, the new code helped me track down a little further into the problem. Seems there is something about MS Paint that the loader doesn't like. I save the image off in paint and when I try and load it, the system blows up. Re-Save it in ArtWeaver still blows up. Create a new image in ArtWeaver and everything works fine, so its something to do with the format that MS Paint uses

I now have quite a bit of the scripting engine working, soon as I get the input stuff done I'll post up a new snapshot of the code and the demo.

[jdarling]

And more information, its actually a power of two thing. If I make the bmp file from MS Paint 256x256 instead of 143x107 everything works fine. So, now there needs to be some image scaling done to get everything to work properly

[Andreaz]

Yeah, non power of two texture is not supported by most hardware and if it are it will be without mipmaps and so forth.

So that's really not that much to do about, could use some kind of scaling function when loading the textures, but that will only result in streched textures and longer loading times. It's better to let the users scale the textures beforehand (For example setting the rest of the image to transparent).

This is the main reason to why alpha blending is enabled by default in all rendering functions

[jdarling]

Well, the scripting stuff is wrapped up enough that I feel comfortable letting everyone see it . In fact you can do quite a bit with the scripting engine and whats available through the game engine already. I'd go as far as to say that you could write an entire game .

Download: http://www.eonclash.com/phoenix/Phoenix2006-08-15.zip

The only known issues:
Using Mouse:Hide() causes problems when in windowed mode, Andreaz can you look into this?

I've kept the exe's in place in case people want to download and simply run it (or play with the Lua script, game.lua). The scripting sample is in \Phoenix2006-08-15\demo\Scripting\bin

[jdarling]

Well, I said you could build a game in Phoenix with the Lua scripting support and now I'm backing it up. Granted that the collision detection works horridly (I'm lazy and haven't worked it out proper yet), the game is still playable. You can win or loose. Use the arrow keys to move your dragon, the space bar to shoot. One shot, one kill, one life. You can die, kill all the archers to "Win".

Basically I've utilized the resources from Dragon Flight and created a VERY simple game with them just to prove it could be done.

Download here: http://www.eonclash.com/phoenix/PDF.zip

EXE and Resources included along with all script source.

PS: Cairnswm thanks for a simple enough implementation of a game that I could copy it crappy as I did . Next comes some of the more difficult tasks to wrap up such as the built in collision detection and a few other things.

[Andreaz]

Looks nice indeed

The collision problems is due to that the actual visible pixels of the images is less then the patterns size, you'll have to overide the
[pascal]
// Get the bounds of the sprite, used for rectangular collisions and Optimisations. }
TPHXSprite.Procedure getBounds(var Rect: TRectf); virtual;
// Get the circle for the sprite, used for circular collisions.
TPHXSprite.Procedure getCircle(var Circle: TCirclef); virtual;
// Get the convex polygon for this sprite, used for polygon collisions.
TPHXSprite.Procedure getPolygon(var Polygon: TPolygon); virtual;
[/pascal]
functions to specify better colision rectangles. I'm considering changing how this works as there's some overhead in the current version to the following:

[pascal]
TPHXCollisionInfo = record
Bounds : TRectf;
Radius : Single;
Polygon: TPolygon;
end;

TPHXSprite
property CollisionInfo: TPHXCollisionInfo read FCollisionInfo write FCollisionInfo ;

[/pascal]
Will make it faster and more easy to use. And will make all 3 of the current collision algorims equal (atm Bounds and circle uses the absolute position of the sprites, Polygon the relative postion). Considering changing the collision engine selection to the following aswell:

[pascal]
TPHXCollisionMethod = (
cmRectangle,
cmCircle,
cmPolygon
);

Type TPHXSpriteEngine
Property CollisionMethod: TPHXCollisionMethod read FCollisionMethod write setCollisionMethod;
[/pascal]

This will make the collision selection much easier for the user and it opens up for some additional optimizations aswell.

Probably going to add a 4th collision method, cmPixel using the new TPHXBitmap class for the pixel data.

[jdarling]

Andres, the problem with the way that collision (and many other things) are implemented right now is that it doesn't incorporate well into the scripting environment without me subclassing the existing top levels. Something that I will be doing in a future version.

As an example, I can't override the getRectangle method inside of a script. If instead, Collision.Rectangle were availalble as a property I could change it . Instead I'm not even using the built in collision, and doing it all by hand inside the Lua script itself.

Another thing that this showed me is that we need a collision list available to the scripting engine. Something that says I collided with these other items. Again this will all come from the sub-classing once you get the objects to a completely stable state (code locking the interface is what is necessary).

How long until we get pixel perfect collision working?