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

[Robert Kosek]

Well, I'm glad to hear that you have made progress. Don't freeze your toes in the water.

I am thinking of switching to Phoenix fully because the latest version of Asphyre has become too complex, and I want to start incorporating the ability to go cross platform. The latter can triple an audience, and for casual games that can mean success. Because I'm not aiming for ritzy graphics or effects, and not having the budget for such, Phoenix is the best bet.

I love how well you have followed the KISS (keep it simple, stupid) principle. It makes it easier on guys like me.

[jdarling]

And finally the status of the Tile engine is as follows; more or less the thing that is done so far is the rendering and layer handling, and only for normal rectangular grids, havn't really came up with a good way of handling isometric grids and collisions and such... It's easy to design a tile engine for a specific game, alot more troublesome to make one dynamic enough to support rpg's platforms and isometric games at once

Andreaz, you might want to take a look at how I handled this in GIE (full source and exe at: http://www.eonclash.com/ViewProduct.php?ProductID=15)
Basically I provide for an X and Y offset and an X odd offset that is added to the tile base position. This allows you to edit and preview square, iso, and hex tiles easily within GIE. Granted this only gets you stagger maps for ISO and Hex, but you can also add a rendering flag that states how the step should occur.

Its been a long time since I played with GIE, but I think I remember enough of the code to explain it if it doesn't make any sense. The down side is that its a Delphi application and not an FPC application

[wagenheimer]

So, Robert Kosek, i was some time ago finished the second game, using the Phoenix Engine, Abra Academy, but for windows, i did have problems with the portals that did not see with good eyes OpenGL games for Windows. =(. So i did have to convert all my game to Direct3D, and i did use Asphyre 4 for that. My first ideia was first to try to convert Phoenix to be Also Direct3D Compatible, but my time was low, and i did give up, and i did do some frankstein convertions to make the game Asphyre Compatible (I Did converted the GuiEditor, Path Moves).

But for Mac, OpenGL is the only viable engine.

I want to convert my game to be Mac compatible, somebody here did compiled sucefully Phoenix on a Mac? I think that if Phoenix goes fine on Mac, it´s not so hard to create some "conversion routines" that will make a simple conversion between Asphyre and Phoenix possible source codes....

[Robert Kosek]

I honestly don't like working with DirectX, no matter how nice it looks. There is so much grunt work to do to even load a texture and draw it on the screen that it isn't funny. I've worked with OpenGL (anyone who remembers my Pascal Rocks! wallpaper saw some of the source for this) for a long time even though I'm not particularly good at 3D math; I can work with and enhance Phoenix far more than I can Asphyre.

Graphics are overrated to an extent. If it is the selling point of your game then you certainly need them. However, when people still play Stars! and hope for a sequel, any sequel, the absolute last thing on their mind is graphics. It is all in the game, the strategy, the challenge. I won't rant, but I wrote on this recently in my blog about Petroglyph's new RTS, their failure with EaW, and how an ancient (and now completely ugly) game totally trumped them.

The more I read about Phoenix and browse the source code, the more I like. Making the library act like the standard Delphi canvas is pure genius.

[Robert Kosek]

Proof that using Phoenix is easy:

I wrote a testbed incorporating a turnable freighter in 20 minutes from the included template in Turbo Delphi. I took an image I knew of that was 20 frames worth of rotation, turned it into a PNG and then made it into a 5x4 grid. 4 minutes of processing. Getting the basic template working took a little more effort as I forgot to copy the DLLs. I easily got my image in, rotating, and my framerate appearing in the window title within in under about 10 minutes. The delay was caused by a minor bug I can't quite track down (showing the frame rate hid the freighter somehow). After that I included a fullscreen toggle in no time at all, complete with reloading images and so on.

It totals only 90 lines and is really easy to understand. It even averages 5,300FPS.

Sum total I learned to use the images, input, screen, and timer objects in less than 30 minutes. Now I'm starting to get ready to have a bit more fun in making something that is more of an actual game.

Here's my code for those interested:

unit Main;

{$IFDEF FPC}
{$mode objfpc}{$H+}
{$ENDIF}    

interface

uses
  Classes, SysUtils, Math,

  phxBase,
  phxScreen,
  phxImages,
  phxInput,
  phxTimer;


procedure MainLoop;

implementation

//------------------------------------------------------------------------------
procedure MainLoop;
const
    TurnSpeed = 12;
var Screen:   TPHXScreen;
    Image:    TPHXImage;
    KeyBoard: TPHXKeyboard;
    Timer:    TPHXTimer;

    Rotation: Single;
    Switched: Boolean;
begin
  // Get the window
  Screen       := TPHXScreen.getInstance();
  Screen.VSync := True;
  KeyBoard     := TPHXKeyboard.Create;
  Timer        := TPHXTimer.Create;

  // Open the window
  if not Screen.Open('Rotating Freighter Example', -1, -1, 800, 600) then Exit;

  Image := TPHXImage.Create;
  Image.LoadImage('robominer.png');
  Image.UpdatePatterns(128,128);

  Rotation := 0;
  Switched := False;

  repeat
    KeyBoard.Update;
    if (KeyBoard.Keys[VK_RALT] and KeyBoard.Keys[VK_RETURN]) and (not Switched) then begin
      Screen.Close;
      Screen.Fullscreen := not Screen.Fullscreen;
      Screen.Update;
      Screen.Open;
      Image.Clear;
      Image.LoadImage('robominer.png');
      Image.UpdatePatterns(128,128);
      Switched := True;
    end else if not (KeyBoard.Keys[VK_RALT] and KeyBoard.Keys[VK_RETURN]) then
      Switched := False;

    Timer.Update;
    if Timer.FrameCount mod 50 = 0 then
      Screen.Title := Format('Rotating Freighter Example [%dFPS]',[Timer.FrameRate]);

    // Clear the window
    Screen.Clear();

    // Turn the ship! Woo!
    if KeyBoard.Keys[VK_LEFT] then
      Rotation := Rotation - TurnSpeed*Timer.FrameTime;
    if KeyBoard.Keys[VK_RIGHT] then
      Rotation := Rotation + TurnSpeed*Timer.FrameTime;

    if Rotation <0> 359 then
      Rotation &#58;= Rotation - 359;

    Image.Draw&#40;336,236, Trunc&#40;Rotation&#41; mod 20&#41;;

    // Flip the buffers
    Screen.Flip&#40;&#41;;
  until &#40;Screen.Visible = False&#41;;
end;

end.

[Andreaz]

Proof that using Phoenix is easy:

I wrote a testbed incorporating a turnable freighter in 20 minutes from the included template in Turbo Delphi. I took an image I knew of that was 20 frames worth of rotation, turned it into a PNG and then made it into a 5x4 grid. 4 minutes of processing. Getting the basic template working took a little more effort as I forgot to copy the DLLs. I easily got my image in, rotating, and my framerate appearing in the window title within in under about 10 minutes. The delay was caused by a minor bug I can't quite track down (showing the frame rate hid the freighter somehow). After that I included a fullscreen toggle in no time at all, complete with reloading images and so on.

It totals only 90 lines and is really easy to understand. It even averages 5,300FPS.

Sum total I learned to use the images, input, screen, and timer objects in less than 30 minutes. Now I'm starting to get ready to have a bit more fun in making something that is more of an actual game.

Here's my code for those interested:

Great work Robert, there's thing there even i havnt considered, like switching fullscreen, there was a lot of work in glxtreem to make that work good.

And what i think you wull like is that you can shawe of 5 mins of the work in the above project just from the enhancements in the new version ,

1. No need for the (not Switched) anymore: The input supports removing states: KeyBoard.States:= KeyBoard.States - [isButton32];
2. Image editor is alot bettter, much easier to add the patterns, no need to update the matterns manually (or even considering the size, just throw em into the image and define the patterns by easy point and drag!)

One thing to note through, shure the canvas class is nice but be warned that it lacks in performance through, there's no possibility to cache the geometry as there is in the imagelist. But for simple games, like minesweeper and such it will be sufficient!

And latly, no need to say phx doesnt support fancy graphics, it does, thrust me, you can throw all sorts of cool pixelshaders and fancy effects if you'd really like (pixelshader support is a planned feature btw! And the particle engine is top notch aswell if i may say so, havn't seen many other s out there that matches what it can do and with the speed it does it (it's the fifth or so particle engine i made)

Great to hear phx works in turbo delphi aswell, please let me know if you runs into any problems!

Thanks for the great feedback and keep up the good work, i really look forward to what you can sqeeze out of my lib!

(And btw, you forgot to free the imagelist and keyboard in your project, a common issue in my demos aswell, memory leeks is for everyone!)

[Robert Kosek]

Mmm... true. But leaking 4kb of ram out of 2gb available just makes Windows work a little. (I'd never write it that way in a SERIOUS application. This was just thrown together to see how fast I could do it.)

From what I've seen the particle system is excellent even though you don't include negative growth (shrinkage) in the editor. I've not written a real particle system myself, but I'd love to see a percentile timer on the color list so you can set the lifetime of the colors. Think of a propane flame and you see a bright semi-clear white-blue that quickly fades to a bright azure tip that is smaller. I'd also ask that you can spawn a particle system/effect in a given direction.

Overall your work is quite excellent, and while the canvas might not be optimized it provides a good example base foundation for those who like the "geometry wars" look alike games. (Not that I'm one, but hey.)

Maybe we could even get side or top down rendering of models implemented. Then we could imitate games like Flatspace, etc.

[jdarling]

Andre, you should consider using a modified factory framework where all objects in Phoenix add themselves to a list and upon the application existing it automatically cleans up any that were forgot and writes it to a log. That way devs have a quick and easy one stop to see what they forgot to free . I do this in JS and it works like a charm. Especially since in JS many of the objects are created in a script and can easily be lost in the shuffle.

[Andreaz]

Mmm... true. But leaking 4kb of ram out of 2gb available just makes Windows work a little. (I'd never write it that way in a SERIOUS application. This was just thrown together to see how fast I could do it.)

Hehe, so true

From what I've seen the particle system is excellent even though you don't include negative growth (shrinkage) in the editor. I've not written a real particle system myself, but I'd love to see a percentile timer on the color list so you can set the lifetime of the colors. Think of a propane flame and you see a bright semi-clear white-blue that quickly fades to a bright azure tip that is smaller. I'd also ask that you can spawn a particle system/effect in a given direction.

Negataive growth is supported ofc, could call it a editor bug

The color list is more or less percentive based, if you say add two blue and two white it's blue the first 33% of its life, then ut fades to white and are white the last 33%. I had a time based version there for a while until i realized that i have a variance in the particles life times, tus a fixed time for each color wasnt good enough. But you can add alot of colors to fade between to get just the effect you want.

There's a spread and direction variable for just that

Overall your work is quite excellent, and while the canvas might not be optimized it provides a good example base foundation for those who like the "geometry wars" look alike games. (Not that I'm one, but hey.)

Yeah, ofcourse just wanted to let you know that using the canvas calls to render alot of stuff really isnt the way to go. Better to render the canvas stuff into a displaylist and then just rendering the displaylist instead. New feature discovered!

Maybe we could even get side or top down rendering of models implemented. Then we could imitate games like Flatspace, etc.

That was actually a great idea, consider it added to the todo list, not for 1.0 ofc Have alot of this done for glxtreem already, so its quite easy to port and modify for phx, even through theres some optimizations and reorginisation i want to do for the meshes.

[Robert Kosek]

There's a spread and direction variable for just that

Yeah, but that's in the effect "template" and not the system. Say I want a meteor trail that looks the same but I want it to emit in a different direction each time. Right now there's no way I can say
[pascal]ParticleSystem.Direction := -90;[/pascal]
or
[pascal]ParticleSystem := ParticleManager.Emit('bang',x,y,angle);[/pascal]
so I can "trail" the meteor object. Or at least not that I've found. I'm still reading your source code to learn everything.

I really look forward to the next version!