Prometheus News

[code_glitch]

Currently the units are:

Prometheus_Core
Prometheus_Video
Prometheus_Audio

Although this can be a little long to type out so I tend to use Prom although your idea is good too. I prefer not to have tAudiofor the audio type to avoid confusing the newbies this is aimed at and rather just have it as Audio if you see what I mean...

Anyway, cheers for the reply.

[code_glitch]

Almost half a year since the last post here ok not really but things are going nicely. OpenGl is speeding Prometheus up, I'm testing it on windows x86 and x64 Ubuntu x64 and meego i586 at the moment, but the theory is, if you have sdl/opengl it should work for you.

from revision 42 onwards, sdl is being phased out for better performance (keeping a gl texture and a sdl_surface in memory is too much), rotation, scaling, resizing, drawing, loading, tileset support, basic XML support, event management support are all functionality that should be working on r42 only to name a few...

Hopefully new releases will not be so far apart in the future since I've been on a bit of a development break lately.

Oh, and lastly, the tutorials I am writing as part of the PGD tutorial base programme in sdl will also be ported, shortened and sped up in prometheus too so if you're after a library to speed up your dive into programming feel free to check it out.

Almost forgot, I'm writing up all spec data on prometheus so you all know what uses what (openal, opengl, sdl) where its development is at, changes that will be made and etc.

Stay tuned,
code_glitch

[gintasdx]

Nice to hear it's working on MeeGo. Maybe will take a look into this engine.
There is already another engine with same name http://code.google.com/p/prometheus-engine/

What I am missing in your engine is functions to load sounds and textures from stream and collision functions would be really good.

[code_glitch]

'load sounds' that is on its way. Its already possible to do so with the current sdl_mixer based release of Prometheus_Audio but has high memory usage as it loads the entire sound to ram... Textures from stream is partially implemented since it can load from Sdl surfaces in memory with the Image.LoadFromSurface() procedure and collision functions is a neat one I did not think of yet (weekend coding perhaps) once the bugs in my new opengl code and memory optimisations are sorted.

In terms of the engine you mentioned, it is not really direct competition since Prometheus or PrometheusLib (full name) is not an engine in itself but a colelction of data types, functions and procedure much like sdl to make coding a lot easier whilst retaining the best flexibility. However, one of my main focuses is on performance which is usually improved on every revision. (ran some benchmarks a while back here: http://www.pascalgamedevelopment.com...c-benchmarking but might I add we are now 15 revisions later. Unfortunately I am in the process of writing the documentation so it may be cumbersome to pick up although nearer the start of the project I wrote this article which may give you a feel of what prometheus aims to achieve for making coding easier: http://www.pascalgamedevelopment.com...brief-overview

however, the last link is seriously old and considerably slower it gives a good rough idea on the project...

Hope this helped you in some way and since I am getting quite a bit of free time expect many new releases in the next few weeks. Major one coming up this weekend.

PS: Do NOT use the latest release of prometheus, it is riddled with bugs as meego experimentation revealed... I would revert to r37 or around there until I commit the next revision. Almost forgot, due to my over-zealous linking of external libraries prometheus binaries are around 700kb but use 1-4 megs of ram for simple applications... If you are planning to run this on am Amstrad you may encounter problems. Although I doubt they have opengl anyways

EDIT: scratch that going back revisions, new revision out wed-thur. I'd recommend waiting it out until then if you can XD

[gintasdx]

Well I will wait for a stable release. There is a dead game engine which may come handy for you S2DL for making game states engine and collisions.

Goodluck!

[code_glitch]

Man looking at that makes me grin - I have the bases covered from other engines in Prometheus. Heading towards a stable release soon by the looks of it (I reckon around r65 or so).. At the moment, its mainly bug fixing since I removed a LOT of sdl garbage for OpenGl so now everything is like wtf I was using that sdl resource now its gone... So its along the lines of whipping up some super simple test programs like this:

program TestApp;

uses
    Prometheus_Vid,
    crt;

var
    Dat: Image;
    c: Int64;

begin
    PrometheusVid_Start();
    CreateWindow(800, 600, 32);
    
    UpdateWindow();
    
    Dat.Load('Data.png');
    
    c := 0;
    repeat
        c := c + 1;
        Dat.Resize(c, c);
        Dat.Rotate(c);
        Dat.Draw(110, 110);
        UpdateCanvas();
        ClearCanvas();
        delay(10);
        until c >= 1000;
        
    writeln('DONE');
end.

Lucky prometheus makes them short XD. Oh and cheers for the pointers to that source - some interesting stuff in there that may just find its equivalent functionality added to prometheus somehow... And thanks for the luck - will definitely need lots of that too.

If you're going meego, perhaps look into Zengl. From what I have heard that will compile on just about anything with a CPU and a decent OS (not to say anything it doesnt compile on yet is not decent) if you don't mind the complexity. Otherwise Prometheus could handle your basic functionality but multitouch is one I need to implement. Might be difficult though, since current event handlers are sdl (under I re-write them haha) and that is not multitouch

cya round on the forums I guess. Back to work time.

[code_glitch]

Still not many prometheus users, but I use it so I might as well publish my code... Just thought I'd let the community know of some upcoming features in prometheus:

-Layer & Tile properties in Map variables
-Implementation of all variables in Map variables for full support
-A new XFont which pre-renders characters from a TTF file for that extra speed boost! YAAA! Good thing here is we can do it all on the fly so we don't need a conversion utility outside your program, although I can make one if required
-In order to get s very small speed boost, a cache system is being added to Maps so that if your data reads 5 5 5 5 5 5 5 Prometheus only searches tilesets once rather thatn 7 times, although it purely depends on the map... Although the next step is to render the same tile everywhere: Ie. All tile code 5 rendered then 6 then 7 rather than sequentially by position. This, of course, will have switchable modes.
-Sdl code is being phased out some more, and hopefully will now be removed from resource loading in favour for code based on andrus amazing zengl, window code to follow.
-Extensions to the window creation system will let you have full screen, resizeable, named, iconed and themed windows with/without borders and etc...
-And last but not least I may release a snapshot of the new OpenAL Prometheus_Audio depending on whether the bugs get fixed.

So all in all, a dabble more than your regular update, and in my mind a well earned refresh for Prometheus. All this in the next few days to 2 weeks at the latest. Hoorah!

[code_glitch]

A little bit more of a progress update:

The old Prometheus_Vid naming convention is GONE! We now have 'modules'. PM_Window for example, pertains to controlling your window, size, colour depth, name... PM_Utils has your StrToInt, StrToReal, Pause etc... That way, only include what you need.

Window management has been written from the ground up as well as event handling, so far its X11 only but this weeks schedule should see WinAPI support too
If you prefer to use OpenGl instead of Prometheus, you can do so - Prometheus sets up an OpenGl context on your OS for you, image loading (PNG first) is also sheduled for the next few days, so it will give access to your Image.Load, Image.Rotate etc.
Memory usage for window management is down from ~7mib to 5.9mib
No external dependencies - ie. libsdl (dlls on windows)
Executable size is down to 561KiB for a basic implementation, loading times follow suit as well as CPU usage. An OpenGl context 640x480 32BPP has plenty of space in 8mb ram and 10mhz cpu

Thats is so far, Mac support is scheduled - once I get a good VM or something

And a quick sample program as it looks now:

program TestApp;

uses
    PM_Window,
    PM_Input,
    PM_Utils;

begin
    CreateWindow(640, 480, 32);
    SetWindowTitle('Test Program');
    repeat
        ClearCanvas();
        GetInput();
        UpdateCanvas();
        Pause(25);
        until IsClose();
end.

[code_glitch]

Well, the rewrite is coming along nicely - the Linux branch of the new modular system is 'stable' and needs zero third party dependencies with support for TGA and PNG (no auto-detection yet but on its way), I've kicked off the Win32 branch today, the new units out so far are:

PM_Colour - The colour type, used for defining colours
PM_TileSets - Allows you to manage tilesets
PM_Image - Allows you to load, draw, rotate, resize, colourize... Images.
PM_Debug - Using DebugWriteln nd DebugWrite can easily switch to writing to screen, log file or nothing at all with a simple boolean flip
PM_X11Window - Direct access to the X11 management system for windows on the Linux desktop
PM_Window - Access to window management accross all platforms (routes your commands to the appropriate PM_X11Window or PM_Win32Window units at compile time)
PM_Utils - The usual StrToInt, StrToReal etc plus support for clearing some basic arrays with a simple EmptyIntArray(@YourIntArrayVariable); as well as a timer system writen from the sysutils unit.
PM_Event - Handles mouse, keyboard, window manager and other such events
PM_Maps - Access to maps drawing them, loading them from TMX files (CSV/XML encoding) etc.

Under development:
PM_Win32Window and PM_Window
PM_Event
PM_Image
PM_Maps
PM_DataFiles
PM_Network

So thats all for now, still hard at work

[paul_nicholls]

Hi Ben

I have done some simple image type detection in my xeEngine that I am writing for The Probe...

here is that part of the code if you want to try it (seems to work for me):

type
  TImageType = (itUnknown,itBMP,itPNG,itTGA);

function  GetImageTypeFromStream(Stream: TStream): TImageType;
type
  TTGAHeader = packed record   // Header type for TGA images
    FileType     : Byte;
    ColorMapType : Byte;
    ImageType    : Byte;
    ColorMapSpec : Array[0..4] of Byte;
    OrigX  : Array [0..1] of Byte;
    OrigY  : Array [0..1] of Byte;
    Width  : Array [0..1] of Byte;
    Height : Array [0..1] of Byte;
    BPP    : Byte;
    ImageInfo : Byte;
  end;

const
  cBMPSig = $4d42;
  cPNGSig: array[0..7] of Byte = (137, 80, 78, 71, 13, 10, 26, 10);
var
  BMPSig   : Word;
  PNGSig   : array[0..7] of Byte;
  TGAHeader: TTGAHeader;
  i        : Integer;
  OldPos   : Int64;
  Image    : AnsiString;
begin
  Result := itUnknown;

  OldPos := Stream.Position;
  try
    // check for BMP
    Stream.Read(BMPSig, SizeOf(BMPSig));
    if BMPSig = cBMPSig then
    begin
      Result := itBMP;
      Exit;
    end;

    //check for PNG
    Result := itPNG;
    Stream.Seek(OldPos,soFromBeginning);
    Stream.Read(PNGSig,SizeOf(PNGSig));
    for i := 0 to 7 do
    begin
      if PNGSig[i] <> cPNGSig[i] then
      begin
        Result := itUnknown;
        Break;
      end;
    end;

    if Result = itPNG then Exit;

    Result := itUnknown;

    //check for TGA
    Stream.Seek(OldPos,soFromBeginning);
    Stream.Read(TGAHeader,SizeOf(TGAHeader));

    // Only support 24, 32 bit images
    if (TGAHeader.ImageType <> 2) and    { TGA_RGB }
       (TGAHeader.ImageType <> 10) then  { Compressed RGB }
    begin
      Exit;
    end;

    // Don't support colormapped files
    if TGAHeader.ColorMapType <> 0 then
    begin
      Exit;
    end;

    Result := itTGA;
  finally
    Stream.Seek(OldPos,soFromBeginning);
  end;
end;

Using it:

function  TImageBuffer32.LoadFromStream(Stream: TStream): Boolean;
var
  ImgType: TImageType;
begin
  Result := False;

  ImgType := GetImageTypeFromStream(Stream);

  case ImgType of
    itBMP : Result :=  LoadBMPFromStream(Stream,Self);
    itPNG : Result :=  LoadPNGFromStream(Stream,Self);
    itTGA : Result :=  LoadTGAFromStream(Stream,Self);
  else
  end;
end;

cheers,
Paul