Prometheus News

[code_glitch]

More news: Just got some free time and round to that architectural update for Prometheus_Audio. Looks like the final file types will be OGG and WAV. Wav only at the moment, and a glitch prevails: only one file can play at once... but that wont last long. Got there in the end; things are looking cleaner:

program WavDemo();

uses
   Prometheus_Audio;

var
   SomeSong: Audio;

begin
   PrometheusAudio_Start();
   
   LoadAudio('AudioFile.wav', SomeSong);
   PlayAudio(SomeSong);
   
   PrometheusAudio_Stop();
end.

Looking good so far if you ask me. Some major tweaks coming up though. Maybe a release later today. (Been working on it all morning) XD

[code_glitch]

And once again I find myself updating here: Have been committing a bit less lately since its near the end of the year all teachers decide they have to test you on everything *sigh* but heres the current development focus:

-Fire n forget approach to things eg: you make an object that rotates, you don't have to call an update function. Ever. Same thing for updating the screen. Also applies to audio as it updates the buffer on its own thanks to multi threading.
-A more comprehensive range of drawing procedures and functions for graphics including primitives, and am experimenting with gradient fills (not going too well).
-For the core unit, I'm working on a new type of resource file with its own editor for databases and for packing files along with new resource management.
-I am about to get a tablet - multi touch support would be nice XD. This is still in the is it feasible stage but there is a chance it will be in there for an early 2011 sdl release and an optimised Gl release later on.

The timescales aren't pretty but I have plenty to go through - especially since I am now an IT techie for our company (hooraah) as a part of the Young Enterprise sheme ongoing here in the UK.

[arthurprs]

Maybe you should prefix the library types, like

Audio -> TPrAudio

[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

[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

[code_glitch]

Well folks its sure been a long time - no this isnt dead, I'm still toying with the long term workings of prometheus and I think I've just about cracked how I want it to look and feel. I've already posted some much needed bug fixes to the SVN over on sourceforge as well as cleaned up the downloads and added a snapshot from today... Which I'm ashamed to admit is already obsolete courtesy of me finding some badly written code in the PM_x11Window unit for X11 windows producing the wrong behvaiour as a result of premature optimization. I know. tsk tsk tsk, though on a more exciting note heres some new stuff thats coming as soon as I get all pretty looking and some stuff I've just added...

-Rewrite of XML based TMX map files from TileD to support properties on layer, map and tileset levels [Done, SVN & Snapshots] (followup commit coming soon since there seems to be a glaring ommission in loading said properties int eh current version...)
-Added support for editing and saving loaded config files from PM_Config [Done, SVN and Snapshots]
-Added support for loading BMP files [Done, SVN & Snapshots] - THOUGH I dont remember writing this and its there so... Could be BIG BUG
-Loading an image from an OpenGL surface in memory [Done, SVN & Snapshots]
-Modular architecture ala ZenGL (sort of but not really) in the form PM_Window, PM_Image, PM_Colour.... [Done, SVN & Snapshots]
-Support for loading the zfi files for using ZenGL fonts [85% done, adding in a week or so]
-FBO based render to image [75% done, adding in a week or so]
-Scrapping the placeholder PM_Debug unit for better error handling and a propper one to trace bugs accross pointers and threads [50% done, adding in a couple of weeks]
-Support for rectangle and simple geometric 2D collision detection [25% done, adding in a week or two]
-3D contexts and support for the 3rd dimension [Just started work... Might be a short while ]
-OpenGL lighting sources [Just started work... Might be a short while ]
-Long awaited PM_Audio unit for WAV and OGG, now on the 9th or so rewrite with 3d support [Somewhere 150 lines in, should be around the time the 3d unit rolls out]
-Android test on ARM [This is ongoing for all the above with sdl 'window' and event handling... OpenGL ES tends to cause some havoc a bit everywhere so...]
-Wii test with PowerPC [Same deal as with android though the OpenGl goodness is easier to come by so maybe before Android]

So thats where it stands for now, more news coming soon and hopefully a few more boxes ticked before college starts in a week and a bit so stay tuned