PDA

View Full Version : Prometheus News



code_glitch
10-10-2010, 11:12 AM
Hey all to the new and very shiny Prometheus forums (thanks will). This post just to let you know Prometheus is no longer on google code (painful) and now on sourceforge here: http://sourceforge.net/projects/prometheuslib/files/ but since I have only just set this up, I have yet to add the content.

Keep your eyes peeled on this thread/post for any new prometheus news.

cheers,
code_glitch

code_glitch
23-10-2010, 11:53 AM
A quick update, due to recent time constraints, I find that I am too busy working on schoolwork, being a part of the PGD community and working on my code to fully support musicality, and thus will anounce its discontinuation. Sorry if you were expecting it soon like I'd originally hoped but I just dont have the time or resources to work on it any more. I will still throw in a few lines now and then but other than that I have to proclaim it dead. But if you want the source code just PM and I will send it to you.

code_glitch
28-10-2010, 11:50 AM
Again, another quick update:
-The documentation has started taking shape so it will make more sense to users
-In the interest of performance I have started moving bottleneck features to OpenGl (yes rotations and zooms, I'm looking at you)
-The long awaited OpenAl audio unit is finally almost here (its glitchy and only ogg at the moment folks, but that'll be fixed soon)
-The colour system (library management) is switching to variable management
-A new datatype Image will replace pSdl_Surface for video data
-The event management system will soon be updated for performance, common sense and compatibility

hope that fills you in on the time since the last update. Don't know if anyone reads this anymore, but if you do/are reading this, I haven't been slacking off (too much) :) , even with a major system crash...

cheers,
code_glitch.

Ps: these updates due for release later this week to early next week.

code_glitch
20-11-2010, 10:43 PM
Just to let you all know, I am still working on this library. Just had a quick dev break for coursework, but now that everything is easing up a little I might get some free time...

Sorry for the wait. Hope to get the ball rolling again super soon. Just as soon as I figure out where I left off in the OpenAl code...

code_glitch
21-11-2010, 10:49 AM
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
10-12-2010, 07:48 PM
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
11-12-2010, 01:58 AM
Maybe you should prefix the library types, like

Audio -> TPrAudio

code_glitch
11-12-2010, 12:05 PM
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
06-03-2011, 02:41 PM
Almost half a year since the last post here :o 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
07-03-2011, 09:20 PM
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
07-03-2011, 10:22 PM
'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/entry.php?33-Some-graphic-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/content.php?111-Prometheus-Video-A-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
08-03-2011, 09:03 PM
Well I will wait for a stable release. There is a dead game engine which may come handy for you S2DL (http://dl.dropbox.com/u/17084229/s2dl.zip) for making game states engine and collisions.

Goodluck!

code_glitch
08-03-2011, 11:53 PM
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
08-04-2011, 09:43 PM
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!

WILL
09-04-2011, 01:19 AM
Still not many prometheus users

I keep telling you... documentation... :)

code_glitch
09-04-2011, 10:57 AM
Oh yes, that thing... Its getting there. According to the pascal doc generator thing I need to make an XML file? At the moment, documentation covers 15% of video, so I'll try and get it up to the 80s or 90s by the next few days...

Aside from that, implementation of Prometheus_Video is swelling quite rapidly now so thats some good news at least. Especially looking forward to the fonts improvement since It seems to be 10% slower than anything else ;) Perhaps I'll commit that to SVN first.

gintasdx
09-06-2011, 08:53 PM
Yo! So what is going on inside the development? No fresh news and I hope there is some tasty news about Android part.

code_glitch
10-06-2011, 06:53 AM
Funny you should bring it up gintasdx, I'm scheduling (or hoping to) release a new major revision. Recent updates include:

-Basic particle effects
-Marginally lowered RAM & Memory leaks
-Bug fixes for drawing and everything else, a few flaws where found during LD20 and they needed to be fixed.
-Super font type postponed due to it being slower then SDL defeating the point
-Android will most likely need a slimmed down revision - this is currently R&D and testing is on the x86Android project since procuring android hardware has been harder than expected.
-Touch support (single point) is 'supported' by SDL, multi-touch would be nice and is planned for when SDL event procedures are re-written in prometheus_core. Better performance expected/
-Documentation improvements, about 40% of everything (literally) done now. :) Getting there.


So in general progress is being made, plans to expand the tweakability are there but not yet high priority, phasing out SDL for all but resource format loading is underway and should you not need to load a million formats under the sun, I'm looking at specifics. Also, interoperability with OpenGl and SDL directly is also improving.

Hope this posts since I've been having login issues with PGD lately...
cheers,
code_glitch

code_glitch
16-06-2011, 06:12 PM
Here we go for another update... After a decent chunk of coding in the last 24 hours, progress as it stands:

Prometheus_Vid in SVN is still not stable.
Window handling is not done by SDL any more... For X11 systems anyway. Working on the Win32 fad ;)
Resource loading will no longer happen with SDL thanks to the new IDF (Image Detection Framework) which is a fancy name for image format detection and launching appropriate loading procedures... Which once implemented should mean the end of the SDL inclusion in Prometheus_Video at last, hooray, giving you a few MBs of your memory back and a big speed boost (around 30% at a guess).

That is, once OpenGl starts rendering correctly again to the new window management...

Prometheus source structure is changing so you it will have a Prometheus\ folder in Src\ rather than Video, Core and Audio directly which can be annoying on large projects.
Prometheus_Version module will likely NOT be in the next release since I have yet to format PDFF (Prometheus Data File Format), PDTF (Prometheus Data Transmission Format - yes, Prometheus will soon do networking :)), PMFF (Prometheus Meta File Format), PEDF (Prometheus Encrypted Data Format) and lastly PCDF (Prometheus Compressed Data Format) which will provide some interesting developments in the next month or two... And yes, Prometheus will still support other data formats, but sometimes you want high speed, on the fly data processing or you want to reduce the number of resource files you have right? And thats why all you need is a Prometheus File packing tool and you're set to go.

Warning: I would not recommend using PEDF for sensitive data - I am no cryptology expert, it might keep the end user tweaking settings etc... But it is easily reversible/brute-forceable despite the fact you can have anything up to a 255 character ASCII key (thats 255^255 possibilities), its a simple cipher :p

Oh, and androidx86 is not playing nice with anything I try to run it on... Not mention I have yet to figure out the compiler first so check in in the next 1-2 months for an update on that. Meanwhile, I'll be rewriting management for X11, Win32 and perhaps looking for a person lucky enough to have Mac to test my Mac implementations of it... Unless it uses X11 and is compatible with linux X11 code. Which, knowing Apple, I doubt somehow. :)

All of this reminds me... I'll have to document all this too now :/

code_glitch
23-09-2011, 10:14 PM
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
07-11-2011, 07:02 PM
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
07-11-2011, 10:18 PM
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

code_glitch
08-11-2011, 10:19 PM
Neat stuff paul, I take it the xe Engine treats you nicely then? The only problem in no auto detection YET is that a while back I wrote a separate unit that identifies the file type based on the first few bytes ord numbers. I just need to find a nice way of implementing it. I'm thinking I could just commission a PM_FileTypes unit and make something like



var
ft: ANSIString;

begin
ft := GetFileType('SomeRandomFile');
if ft = 'PNG' then // and so on...


I've just had so much stuff to do recently I've barely had any time to implement it :) All the stuff mentioned above is stuff I have already played with, although there are some problems in Net as much of the code has never been tried by me, and DataFiles runs so fast on the CPU it thrashes the hard drive cache and thus gets killed for memory violation; due to accessing a file while it is being updated by the OS, so timings need to be updated as well as some synchronization procedures. But good progress all round.

code_glitch
25-11-2011, 09:28 PM
A tad more news in the unwind of code leading up to exam week - the PM_DataFiles unit is in its first implementation although at the moment it is quite limited - a maximum of 255 characters for the Name of a record and 4k (4096 bytes) for the actual value :( Although in its second revision this should be rectified.

The framework for detecting file types in undergoing final tests but will be quite limited out of the box - only mp3, wav, ogg, png, jpeg and tga detection although more could be added by modifying the constants line in PM_FileTypes, all courtesy of keeping the weight of prometheus down.

In other news, it has been found that the UPX utility can squeeze prometheus into a poultry <100k for a default compilation - no DLLs etc required so this is quite a bit lower than previous iterations.

Also, looking out for a jpeg/bmp loader as well as a PM_DataFS unit that can store multiple files inside a Prometheus Data Storage file (.PDFS) as a sort of filesystem - such as raw proemtheus images ;) and since each record eats up 4k at the moment, I'm implementing a basic compression system for all that white space too :)

So lots of stuff going on, hopefully rolling out at the end of the weekend or in early next week.

Just a few teaser stats on the data file system: loading a 21mb data file of 5200 records takes you a cool 51ms on a 1.3ghz dual core machine with an ageing stock, mechanical HDD... Thats around 375mb/s for those that were counting :D

650

paul_nicholls
25-11-2011, 11:40 PM
Hey Ben,
here is my BMP loading code I wrote for my xeEngine:


unit unit_bmp_loader;
{$ifdef fpc}
{$mode Delphi}
{$endif}
{$H+}

interface

uses
Classes,
unit_ImageBuffer32;

function LoadBMPFromStream(Stream: TStream; Buffer: TImageBuffer32): Boolean;
function LoadBMPFromFile(FileName: String; Buffer: TImageBuffer32): Boolean;

implementation

uses
SysUtils;

type
//File information header
//provides general information about the file
TBITMAPFILEHEADER = packed record
bfType : Word;
bfSize : LongWord;
bfReserved1 : Word;
bfReserved2 : Word;
bfOffBits : LongWord;
end;

//Bitmap information header
//provides information specific to the image data
TBITMAPINFOHEADER = packed record
biSize : LongWord;
biWidth : LongInt;
biHeight : LongInt;
biPlanes : Word;
biBitCount : Word;
biCompression : LongWord;
biSizeImage : LongWord;
biXPelsPerMeter : LongInt;
biYPelsPerMeter : LongInt;
biClrUsed : LongWord;
biClrImportant : LongWord;
end;

//Colour palette
TRGBQUAD = packed record
rgbBlue : Byte;
rgbGreen : Byte;
rgbRed : Byte;
rgbReserved : Byte;
end;

PBitmapPixel = ^TBitmapPixel;
TBitmapPixel = packed record
b,g,r: Byte;
end;

function LoadBMPFromStream(Stream: TStream; Buffer: TImageBuffer32): Boolean;
var
FileHeader : TBITMAPFILEHEADER;
InfoHeader : TBITMAPINFOHEADER;
Palette : array of TRGBQUAD;
BitmapLength : LongWord;
PaletteLength : LongWord;
ReadBytes : LongWord;
Width,Height : Integer;
BitmapPixels : PBitmapPixel;
BitmapAddr : PBitmapPixel;
BufferRow : PRGBAArray;
x,y : LongWord;
OldPos : Int64;
begin
OldPos := Stream.Position;

// Get header information
Stream.Read(FileHeader, SizeOf(FileHeader));

if FileHeader.bfType <> $4d42 then
// not a BMP file!
begin
// reset position
Stream.Seek(OldPos,soFromBeginning);

Exit;
end;

Stream.Read(InfoHeader, SizeOf(InfoHeader));

if InfoHeader.biBitCount <> 24 then
// only supports 24 bit bitmaps!
Exit;

// Get palette
PaletteLength := InfoHeader.biClrUsed;

if PaletteLength > 0 then
begin
SetLength(Palette, PaletteLength);
ReadBytes := Stream.Read(Palette,PaletteLength);
if (ReadBytes <> PaletteLength) then
begin
// MessageBox(0, PChar('Error reading palette'), PChar('BMP Loader'), MB_OK);
Exit;
end;
end;

Width := InfoHeader.biWidth;
Height := InfoHeader.biHeight;

Buffer.SetSize(Width,Height);

BitmapLength := InfoHeader.biSizeImage;

if BitmapLength = 0 then
BitmapLength := Width * Height * (InfoHeader.biBitCount Div 8);

// Get the actual pixel data
GetMem(BitmapPixels, BitmapLength);
try
ReadBytes := Stream.Read(BitmapPixels^, BitmapLength);
if (ReadBytes <> BitmapLength) then
begin
// MessageBox(0, PChar('Error reading bitmap data'), PChar('BMP Unit'), MB_OK);
Exit;
end;

BitmapAddr := BitmapPixels;
// copy bitmap pixels to buffer pixels
for y := 0 to Height - 1 do
begin
BufferRow := Buffer.ScanLine[(Height - 1) - y];
for x := 0 to Width - 1 do
begin
BufferRow^[x].r := BitmapAddr^.r;
BufferRow^[x].g := BitmapAddr^.g;
BufferRow^[x].b := BitmapAddr^.b;
BufferRow^[x].a := 255;
Inc(BitmapAddr);
end;
end;
finally
FreeMem(BitmapPixels)
end;
end;

function LoadBMPFromFile(Filename: String; Buffer: TImageBuffer32): Boolean;
var
BMPFile : TFileStream;
begin
Result := False;

if not FileExists(FileName) then Exit;

BMPFile := TFileStream.Create(FileName,fmOpenRead or fmShareDenyWrite);
try
Result := LoadBMPFromStream(BMPFile,Buffer);
finally
BMPFile.Free;
end;
end;

end.

cheers,
Paul

paul_nicholls
25-11-2011, 11:42 PM
And here is my image buffer I use for all my textures and image loading:


unit unit_ImageBuffer32;
{$ifdef fpc}
{$mode Delphi}
{$endif}
{$H+}

interface

uses
Classes;

type
PRGBA = ^TRGBA;
TRGBA = packed record
case Integer of
0 : (r,g,b,a: Byte);
1 : (Value: LongWord);
end;

PRGBAArray = ^TRGBAArray;
TRGBAArray = array[0..(MaxInt div SizeOf(TRGBA)) - 1] of TRGBA;

TImageBuffer32 = class
private
FWidth : Word;
FHeight : Word;
FPixels : array of TRGBA;

function GetScanLine(y: Word): Pointer;
function GetBit(Index: Integer): TRGBA;
procedure SetBit(Index: Integer; Color: TRGBA);
public
constructor Create;
destructor Destroy; override;

procedure SetSize(aWidth,aHeight: Word);
procedure SetBitRGBA(Index: Integer; r,g,b,a: Byte);
function GetPixels: Pointer;

function LoadFromStream(Stream: TStream): Boolean;
function LoadFromFile(FileName: String): Boolean;
function LoadBMPFromFile(FileName: String): Boolean;
function LoadPNGFromFile(FileName: String): Boolean;
function LoadTGAFromFile(FileName: String): Boolean;

property Width : Word read FWidth;
property Height: Word read FHeight;
property ScanLine[y: Word]: Pointer read GetScanLine;
property Bits[Index: Integer]: TRGBA read GetBit write SetBit;
end;

implementation

uses
SysUtils,
unit_bmp_loader,
unit_tga_loader,
unit_png_loader;

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;
{ SetLength(Image,Stream.Size);
Stream.Read(PAnsiChar(Image)^,Stream.Size);
if Pos('TRUEVISION-XFILE',Image) > 0 then
begin
Result := itTGA;
Exit;
end;}
finally
Stream.Seek(OldPos,soFromBeginning);
end;
end;

function NewRGBA(r,g,b,a: Byte): TRGBA;
begin
Result.r := r;
Result.g := g;
Result.b := b;
Result.a := a;
end;

constructor TImageBuffer32.Create;
begin
inherited Create;

SetSize(0,0);
end;

destructor TImageBuffer32.Destroy;
begin
SetSize(0,0);

inherited Destroy;
end;

procedure TImageBuffer32.SetSize(aWidth,aHeight: Word);
var
i: Integer;
begin
FWidth := aWidth;
FHeight := aHeight;

SetLength(FPixels,FWidth * FHeight);

for i := 0 to FWidth * FHeight - 1 do
FPixels[i].Value := 0;
end;

function TImageBuffer32.GetScanLine(y: Word): Pointer;
begin
Result := @FPixels[y * FWidth];
end;

function TImageBuffer32.GetBit(Index: Integer): TRGBA;
begin
Result := FPixels[Index];
end;

procedure TImageBuffer32.SetBit(Index: Integer; color: TRGBA);
begin
FPixels[Index] := color;
end;

procedure TImageBuffer32.SetBitRGBA(Index: Integer; r,g,b,a: Byte);
begin
FPixels[Index].r := r;
FPixels[Index].g := g;
FPixels[Index].b := b;
FPixels[Index].a := a;
end;

function TImageBuffer32.GetPixels: Pointer;
begin
Result := nil;

if Length(FPixels) = 0 then Exit;

Result := @FPixels[0];
end;

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;

function TImageBuffer32.LoadFromFile(FileName: String): Boolean;
var
Ext: String;
begin
Result := False;

if not FileExists(FileName) then Exit;

Ext := LowerCase(ExtractFileExt(FileName));

if Ext = '.bmp' then Result := unit_bmp_loader.LoadBMPFromFile(FileName,Self)
else if Ext = '.tga' then Result := unit_tga_loader.LoadTGAFromFile(FileName,Self)
else if Ext = '.png' then Result := unit_png_loader.LoadPNGFromFile(FileName,Self);
end;

function TImageBuffer32.LoadBMPFromFile(FileName: String): Boolean;
begin
Result := False;

if not FileExists(FileName) then Exit;

Result := unit_bmp_loader.LoadBMPFromFile(FileName,Self);
end;

function TImageBuffer32.LoadPNGFromFile(FileName: String): Boolean;
begin
Result := False;

if not FileExists(FileName) then Exit;

Result := unit_png_loader.LoadPNGFromFile(FileName,Self);
end;

function TImageBuffer32.LoadTGAFromFile(FileName: String): Boolean;
begin
Result := False;

if not FileExists(FileName) then Exit;

Result := unit_tga_loader.LoadTGAFromFile(FileName,Self);
end;

end.

cheers,
Paul

code_glitch
26-11-2011, 07:57 AM
Hmm... Indeed that PMB code is very nice indeed, you aren't putting a license on it are you? I hate having to reverse engineer techniques to write my own loaders although it does look simple. I'm thinking JPEG won't be as nice, maybe I should drop support for the low-quality support... I mean, who wants dithering like photos on their apps?!

Cheers for that, got a few hours train ride today so I'll work some more then by the looks of it :)

paul_nicholls
26-11-2011, 09:00 AM
No, I'm not putting a license on it...and I finally got the BMP loading code working after looking at a bunch of online code myself. I'm giving back to the community since it gives to me, so use it how you wish :)

I came up with the image buffer class myself after I tried using some Graphics32 PNG loading code initially and wanted to replace some other classes...

I ended up using BeRo's (http://www.pascalgamedevelopment.com/showthread.php?9861-BeRoPNG-A-very-tiny-but-complete-PNG-loader) PNG loader instead but kept the image buffer as it was rather useful for the textures and loaders to hook into :)

cheers,
Paul

code_glitch
20-12-2011, 03:14 PM
Just another check-in. At this point a lot of stuff works and some does not. Focus is now for XML/TMX support and audio support based on openal. The PNG loader is being looked into after the Ludum Dare entry started producing weird behavior on X11 based systems but not WINAPI based systems - although this is most likely down to bad memory optimization and x11 management.

As a result the entire OpenGL code is being scrutinized and most likely binned for a new system based on FBOs and PBOs for extendability and switchable render targets - perhaps a 'render to disk' option or multiple monitor/window option will arise as a result.

The X11 event management code is being overhauled yet again for better integration as well as for mouse support - Mac OS X will have to put up with the 'Generic' window handler AKA SDL while linux users benefit from native X11 code and WIN32 users benefit from native WINAPI code that I hope will be released within the next few weeks.

So, what this means for users:
-Faster performance (up to 35% better frame rates and memory management)
-More OSes without touching a single line of code - Mac, Windows, Linux and possible flash (this one is.... complicated ;))
-Audio is on its way
-Using prometheus for proper rendering as well as potentially in multi-monitor setups and support for a 'virtual monitor' which will be elaborated on at a later date!

Stoney
20-12-2011, 03:52 PM
I'm curious, how would you handle Flash? Would you use FlashPascal or something different?

code_glitch
03-09-2012, 12:59 AM
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 ;)

Andru
03-09-2012, 11:53 AM
-Android test on ARM [This is ongoing for all the above with sdl 'window' and event handling... OpenGL ES tends to cause some havoca bit everywhere so...]
Seems everybody now wants to provide mobile OS's support... where have you been few years ago when this was not a "mainstream"? :) Anyway, I wish you fun with development :)

code_glitch
03-09-2012, 02:22 PM
Thanks adnru, not quite the pace you've got ver at ZenGl eh? :D A fair few years ago I had an old nokia brick and was reading the news of the initial symbian - android - ios clash in south africa with no one I knew having any of those devices at the time, and my android phone is only knocking on 1 year old now so I cant say I've had it all that long. As for the other platforms (game console and such) - I could never get FPC to work right for GBA or NDS. Some stuff compiled and ran, but some other sutff remained a mystery XD

Though I see your point in that everyone is moving towards those mobile platforms, though since my code is opengl based and the mobile platforms are OpenGl ES mostly theres quite some similarities and as for compiling for those platforms its turning into quite a polished process as the developper wolrd gets used to this process :) Personally I'm an anti-java supporter though I see its attractiveness when I'm writing the low level code for each platform java gurus take for granted. Might have to look into project cooper ::)

Edit:
Since I've written this theres a teeny update:
PM_MemUtils. Its in the name, load files to ram for faster access as well as byte level manipulations have been added to the SVN and latest snapshot :)

SilverWarior
03-09-2012, 02:30 PM
-Added support for loading BMP files [Done, SVN & Snapshots] - THOUGH I dont remember writing this and its there so... Could be BIG BUG ???


Man this made me laugh.
It seems that you also go and do programing late into the night as I sometimes do. :D

code_glitch
03-09-2012, 09:43 PM
Oh not at all... Never late at night... Early into the mornings ;) lol I never use BMPs and I think I wanted to add it as a 'check that box too' kind of feature but dont remember doing so and the code seems... Generic and incomplete at best - especially since I cant find any sign of loadre coe anywhere but there is a Image.LoadFromBMP() procedure so... Yeah. Glad it made you laugh though :)

Edit/Update:
PM_Maps now supports layer properties loaded straight from TMX files produced by TileD. Should have the map, tileset and tile specific properties all done in a day or two once I iron out a few kinks elsewhere. No gurantees on speed since I did a bit of a slacker job but I'll optimize after its all working right - as I've learnt from my premature optimization mistakes from the past :D

code_glitch
08-09-2012, 05:31 PM
Well, heres where it stands as of now...

-Fixed some behaviour of some functions in PM_TextUtils.
-Loading maps from TMX files now supports properties for the Map, Tiles and Layers. All the places I could find in TileD to save properties in other words.

Whats open in geany right now and being worked on:
-Collisions (2d simple geometric)
-Base64 encoding 'support' to work with Base64 strings - useful for those base64 TMX files and much more I'm sure... :D
-FBO and other image utilities

Edit/Minor update:
While playing around with the slightly flaky X11 windows system I implemented in Prometheus - specifically, as a result of working with resizing and getting things to run smoother, a bug in keyboard key repeats was found. Said bug seems to be a little hard to pin to a wall to zap with some DDT, as I need to run a line when the X server wants to kill the program - after it has finished running, but before it is actually killed...

In the process of messing with contexts and what not a stunning discovery was made: Multiple windows and multiple X displays could be used. Simultaneously. Now although its a bit of a pain to work accross windows/screens, if I could update some multithreading code I wrote a while back and have an easy way of 'plugging in' said thread to each display... :D

At any rate - there Base64 on its way, some bug fixes, better usability and excitingly: multithreading and multi-window and multi-display support coming out of the box in the near future.

PS: the earlier mention to BMP loading is actually a massive bug in itelf: Only the file header recongition and generic loader code was implemented... :)

code_glitch
19-10-2012, 08:12 PM
Another quick update, development has slowed due to college work... But in a wholesome week I should be on vacation once again and thus should have time to implement everything fully, so lots of new stuff rolling out. For now this is whats done on my local SVN mirror that should be made public over the next few days (hopefully):

Maps/TMX:

-The first multithreaded loader of anything that prometheus uses - this one for TMX files (delayed since its behaving a bit erratically as of right now)
-Object layer/group support for TMX files
-Objects in Object Layers in TMX files can have properties that can be read/deleted/modified by client code
-Paths in object layers are now read as arrays of absolute X,Y coordinates to be handled by client code
-Primitive Base64 support in TMX files. Not everything seems to work. ie. limited to tile layers only
-Base64 seems to work


User I/O & Events:

-X11: Fixed a bug with PM_Window never reporting an Idle state

-X11: Implemented 'prefetch' style mouse actions to avoid reporting an event for each pixel change of a mouse motion

Graphics:
-FBO (Render to texture and the like): might be in there. Depending on whether it stos crashing the OpenGL context in X11 and I fix a hanging issue as well as target vanishing...


Audio:

-OpenAL: Looks like we can support 1 RAW audio stream. Not exactly useful, but working on a solution to read formats and play many thigns at once...

Other:
-Collision Detection: Rectangle based collision detection seems to work. Texture/Image based collision detection will be riht after that FBO is happy.


-Android: No peeking, but it looks like headway has been made ;)

Well thats whats made more progress than the rest, and I'm finally proud to announce that it seems like a lot of the issues regarding stability are gone, memory use is more efficient, binary sizes should be going south too over the next few days (no more ~1.1mb ugliness. Although UPX seems to trim it down to 350k tops) as well as gaining some nice usability tweaks as well as performance tweaks (some large blobks of memory are now cahced :D)