• Recent Tutorials

  • Prometheus Video - A brief overview [0.2.1]

    As of version 0.2, there are two twins of each release of prometheus: a stable sdl based branch and its counterpart - the unstable but high performance twin written in OpenGl. I have adopted this practice to better suit the needs of users of Prometheus. If your code is slow, try the OpenGl version. If it crashes, try the Sdl version.

    Of course, if I am to release Prometheus successfully, I will need a wealth of documentation and tutorials. That is work; almost as much as thinking up what prometheus should do and what beginners would want to do along with how to achieve it. Thus development is slow. However, I hope to enlighten the community to the current progress of the Video unit that has been my main focus so far due to around 1 bug for every 2 lines of code in the Audio unit and a small lack of imagination for features to add to the Core unit...

    Now, onto the serious stuff. This is an overview - not a tutorial. This code does compile with the latest version I am currently working on (0.2.1):

    Code:
    program x021_Test;
    
    {$Mode Delphi}
    
    uses
        Prometheus_Vid;
        
    var
        TestColour: Colour;
        TestFont: Font;
        TestImage: Image;
        
        Temp: Int64;
    
    begin
        PrometheusVid_Start();
    
        SetWindowAcceleration(True);
        SetWindowFullScreen(True);
        SetWindowHardwareSurface(True);
        CreateWindow(1366, 768, 32);
    
        TestColour.Assign(125, 255, 255, 125);
        TestFont := LoadFont('MainFont.ttf', 20);
        TestImage.Load('tImage.png');
        
        DrawText(10, 10, 'A line of text to draw on screen', TestFont, TestColour);
        
        Temp := 0;
        repeat
            Temp := Temp + 1;
            TestImage.Rotate(Temp);
            TestImage.Draw(100,100);
            UpdateCanvas();
            until Temp > 359;
    end.
    So lets break it down:
    The variables I use are (funny enough) an image, a font and a colour. Nice enough and they hold exactly what the names suggest: an image, a font and a colour respectively. The datatypes are as follows (on the Sdl variation)

    Code:
    Image = Object 
            Data: pSdl_Surface;  //the modified data to be displayed
            Original: pSdl_Surface;  //the original data from file to be modified
             
            procedure Load(Src: String); 
            procedure Rotate(Deg: Int64); 
            procedure Empty(); 
            procedure Draw(X,Y: Int64); 
            procedure Resize(X,Y: Int64); 
            procedure Scale(Factor: Real); 
            end; 
        Font = Record 
            Size: Int64; 
            Pointer_: Pointer; 
            Source: String; 
            end; 
        Colour = Object 
            R,G,B: Int64; 
            Alpha: Int64; 
            Sdl: pSdl_Color; 
            Int32: UInt32; 
             
            procedure Assign(iR,iG,iB,iA: Int64); 
            procedure Empty(); 
            end;
    And the whole idea of having the procedures within the datatypes is most likely going to stay that way unless I get any objections for good reason. The only other option was to have a load(source) function and use:

    Code:
    Image := Load('tImage.png');
    which I found is prone to memory leaks in some instances. Not the easiest problem for a beginner to fix. =]

    Now that's the variables covered, onto the first calls:

    The ugly 'PrometheusVid_Start()' procedure boots everything up: Initializes libraries, sets defaults and etc... Its an all in one magic bullet for getting it all set up.

    Next up is the SetWindow---(True/False) procedures:
    Acceleration refers to whether Prometheus should use Hardware Acceleration for graphics.
    FullScreen refers to whether Prometheus should make a window FullScreen or not.
    HardwareSurface (name might change since its long and confusing) refers to whether Prometheus should store data in Video RAM or System Ram... True being in VRAM and False in system RAM.

    Thats all the attributes set for making a window... Except: 'CreateWindow(1366, 768, 32)' - this makes the window to the set size, in this case 1366 pixels wide and 768 pixels high with a colour depth of 32 bits per pixel. This procedure also takes into account the values set by the earlier SetWindow---() procedures and automatically makes a video surface to render to. It basically sets everything up for use. For manual rendering on the Sdl versions (this can be done) use Sdl_GetVideoSurface() as a target. I have never experienced a crash doing this. However be warned: if you lock the surface a 0.2.x version of the unit will NOT check to see if it locked and will continue trying to draw anyway. This DOES cause weird things to happen.

    Then we load images with 'VariableName.Load('Source.imagetype')' which will load data from the file 'Source.imagetype' and in my opinion is simple enough.
    This is different for fonts where you have to use 'VariableName := LoadFont('TtfFile.TTF')' since the above implementation has major memory management issues which I am fixing. Expect this fixed by the next release.
    Colours can't be loaded from a file and thus use the 'VariableName.Assign(125, 255, 255, 125)' format. The Assign() procedure gets passed the Red, Blue, Green and Alpha values of the colour you want. If using 32 bit colour on a scale of 0 - 255 and on any other colour depth the values appropriate for that.

    After that 'DrawText(10, 10, 'A line of text to draw on screen', TestFont, TestColour)' is passed the X co-ordinates and Y co-ordinates of where you want to draw the text as integers, the text as a string, the font as a Font and the Colour as a colour respectively. No problems there. This automatically draw the desired text onto the screen where you want it in the colour you want it and in the font you want it in.

    Then a quick loop to demonstrate rotation which uses 'Image.Rotate( DegreesOfRotation )' which takes the data from the Image.Original surface and rotates it onto Image.Data surface ready for displaying. The reason for this is for performance (although not memory footprint) especially memory leaks, quality (repeatedly rotating images degrades quality) and etc... The rotation is CLOCKWISE unlike Sdl to make more sense and rotates by the Given number of degrees (integer).

    The Image.Draw( X,Y ) draws the data in Image.Data at the co-ordinates X across and Y down the screen... Simples.

    UpdateCanvas updates all the stuff you've drawn onto the screen for users to see. Ie your equivalent of Sdl_Flip. PLain and simple.

    To delete data in variables each usually has a deletefont or a Empty() procedure. Note that when you assign/load new data to them Prometheus automatically cleans them out anyway to avoid memory leaks and performance drags.

    And that concludes my first brief overview of prometheus' video unit. Rather long as it is and quite brief it is just a glimpse of Prometheus to let people know I haven't been slacking and if you're interested in prometheus it's on it's way with more information available at http://sourceforge.net/projects/prometheuslib/ (although the dedicated site is pathetic...)

    cheers,
    code_glitch over and out.
    Comments 1 Comment
    1. code_glitch's Avatar
      code_glitch -
      Just a note: 0.2.1 video is uploaded to sourceforge - current developments are moved onto 0.2.2 with primitive support (polygons) and shading. For rotating them I have a good plan - rotate the co-ords since is faster than rotating the rendered image... Lol: It might be natural for you mystic OpenGl and performance gurus, but this is a beginner interface so beginners might have to look at it. Oh well: there are other rotation demos in the code anyway
Comodo SSL