Results 1 to 4 of 4

Thread: Brainstorming: Simplified game making language and IDE

  1. #1

    Brainstorming: Simplified game making language and IDE

    I have had this idea hatch in my mind for some while... To make a programming IDE little similar to Lazarus, although much simpler. It would require only FPC compiler to make executables. User would use written and possibly some visual designing aswell to program games. IDE would create a full fpc source code out of it, adding all the "carbage code" required in freepascal language.

    Theoretically a full application that draws image on screen could look something like this:
    using Window, Input
      window = MakeWindow // I guess name overloading with packages is allowed.
      // It could make it var_window for the fpc source code.
      using nxpascal
        texture = LoadTexture("test.png")
        // Or have the texture list in the IDE, call LoadTextures(TexList1), and Draw using index 0
        // Here could start thread instead, example below
          Draw(texture) // or Draw(texture, 0, 0)
          wait // This calls Application.ProcessMessages
        until keys[KEY_ENTER]
      //window.Free  // Not exactly sure if this is needed, or it it should be written like that, or
    This is just first sketch of idea, but i think it would greatly simplify game making. A package in this case would be a wrapper unit that adds available commands, types and variables. It would be required to make a system unit which adds all basic functions, and that would be autoincluded. I just added nxpascal as example, but basically you can use many graphics libraries in a big mix, if they are all based on OpenGL.

    Also, most importantly, through packages it is possible to make a very powerful code completion. Opening lists of available commands as you type, completing lines with tab key. Language insist of automatically indenting code where proper blocks exists, so it won't be possible to make 2 commands on 1 line. This is for clarity, and requirement for possibly cool features for the IDE.

    Finally thread possibility:
    thread gameThread
        Draw(texture) // or Draw(texture, 0, 0)
        wait // This calls Application.ProcessMessages
      until keys[KEY_ENTER]
    // Auto initialize all procedures and functions in source code.
    // It shouldn't reduce performance or add to the exe size, but lets use them in other procs before it.
    proc CloseProc
    Small issues i didn't fix in that yet:
    - Keyboard and mouse Input is not updated (attach it to Wait?)
    - Threads and procs need own "using" blocks, or write them inside the first blocks?
    Suggestions, ideas welcome...
    Last edited by User137; 26-04-2012 at 01:06 PM.

  2. #2
    As far as I know OpenGL does not support rendering from threads. Maybe something changes with time but if not...
    Also I don't think that proc-oriented style is useful. I'd like object-oriented one.

    As a main (and only) quad-engine developer... hm what can I say. Code abstraction must be as greatest as it can be. Thus can help in fast development later. But I think that if developer really wants to use all low-level stuff (direct opengl management, or winapi etc)
    Theory is - when you know everything but nothing works.
    Practice is - when all works, but you don't know why.
    We combine theory and practice - nothing works and nobody knows why

  3. #3
    Oh, i didn't intend for it to render from many threads at the time. The above thing should work just fine, as there is only 1 rendering thread.

    I don't think this can have support for low level stuff, directly in the code. But you can do that stuff to package functions. They are just almost ordinary pascal units (.pas) and you can do whatever you want in them. However, intention is not that every game would need to make its own helper packages.

    Then also what i think is that many people who are not that familiar with programming at all, would be able to make something with it. And... maybe the language/IDE would fit to more than just games. Thinking about it, its actually not a scripting language, but its not a real programming language either... What is it? The language that is used to make the final source code is irrelevant, it could even be C++, Java or Python. Although limiting factor is mathematical calculations and used symbols. If i'd have to parse them all, then yes something else than FPC could be used. But if i don't touch the math code and let write "A+B div C", then it's directly only compatible with FPC.

  4. #4
    This reminds me a bit of my proof-of-concept project called fpBASCON which is a BASIC to Pascal translator. Using the SDL based game engine I wrote one can do something like this (simple mandelbrot):
    IMPORT egslengine
    DIM  x, y, c, pow,time1,time2 AS integer
    DIM a, b, z, a2, b2, x2, y2, przesx, przesy, przelx, przely AS real
    openwindow (800,600,32,"Mandelbrot")
    backcolour (0,0,0)
    drawtext (0, 20, "MANDELBROT SET")
    drawtext (0, 40, "Press any key to start.")
    pow = 1
    przesx = 0
    przesy = 0
    przelx = 3 / (800 * pow)
    przely = 2 / (600 * pow)
    FOR x = 0 TO 799 
        FOR y = 0 TO 599
                a = 0
                b = 0
                c = 0
                x2 = (przelx * (x + (przesx * pow))) - 2
                y2 = (przely * (y + (przesy * pow))) - 1
                WHILE c < 255
                    a2 = a * a - b * b
                    b2 = 2 * a * b
                    a = a2 + x2
                    b = b2 + y2
                    z = a * a + b * b
                    IF z >= 4 THEN
                    END IF
                    c = c + 1
                IF c = 50 THEN
                    colour (0, 0, 0)
                    colour (255 - c, 255 - c, 255 - c)
                END IF
                dot (x, y)
    colour (0,0,0)
    drawtext (0,0,STR$(time2-time1)+" ms")
    With the keyword IMPORT one can include all fpc units. All keywords are in uppercase, procedures and functions from the used units are in lowercase.
    Best regards,

    Pulsar2D framework:


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
Comodo SSL