Page 1 of 4 123 ... LastLast
Results 1 to 10 of 36

Thread: Community Engine Announcement Discussions

  1. #1
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45

    Lightbulb Community Engine Announcement Discussions

    I think one of the first things to look it is the architecture of how we build this. As in, what units will supply what functionality, what will it be based on (D3D vs OGL and such debates need to happen), how it will be structured (object wise and structure/class wise) and how it will be used (calling conventions and the like). Also, how much freedom do we award the pogrammers using this engine? Should they make a game that uses this engine (like a lot of current oferrings) or compile their code into our engine or run their game inside the engine on a higher level (basically like a script).

    That said -

    • I believe the requirement for delphi compatibility explicity is possibly redundant as FPC and delphi now share the core compiler code (correct me if mistaken) but delphi has its own FCL/LCL-esque equivalents/extensions? As I understand fpc code -> delphi is ok but latest delphi -> FPC = not always ok. Again, please correct me if I'm mistaken.


    • I know that the Pascal community prefers OpenGL a LOT but from what I see a lot on a day to day basis is that compliance for the masses is 2.1 + Extensions. Meanewhile, DirectX 9 is ubiquitous - even under gallim


    Also, if anyone has components/code/engines/libraries they work on in private and wouldnt mind submitting to this engine please drop a note as I think it might be worthwhile to 'cobble' an engine together from code already written once we have a rough idea to the above questions to test it out in some sort of useful environment (A PGD challenge this could be? 'make a game/demo with the engine' perhaps?) and using those results to refine it further.

    Just a few thoughts as to what the next step I would take if this were my project based on my experiences. To be completely frank, if we're after a very basic, quick and dirty system I'd be tempted to go with ZenGL on graphics (as its faster than native OpenGL code to write but rather quite fast) and some utilities on the side. Personally I find myself re-using a lot of my config handler, TMX loader and various utility functions a whole lot, so for me that'd already be pretty close to what I work with currently
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  2. #2
    DirectX is unfortunately bound to Windows, and I guess that would put some members of the community unable to use the engine. Regarding OpenGL, I think we should use >= 3.1 - the API went a massive change in 3.1 (no more fixed pipeline), and regarding compliance - even my 2005 integrated GPU laptop supports OGL 3.1, so I don't really suppose there's much sense in going back as far as 2.X.

    I could probably provide some data structure code - I have some various purpose trees, tries, lists et cetera. Eventually I could also try (well, I'm already working on that) to create some CFI for awful, allowing to use it as in-engine script language, but I think we'd be off better using Lua or something.

    We will also have to agree on what license to use. I personally suggest zlib or MIT, but I'll be happy to listen to other options (as long as it's not GNU GPL cancer).
    Last edited by Super Vegeta; 25-04-2014 at 10:34 AM.

  3. #3
    I don't see anything wrong with MIT at least, and it is compatible with GNU GPL too.
    edit: Might actually prefer zlib.

    You can freely use nxPascal source code https://code.google.com/p/nxpascal/s...%2Ftrunk%2Fsrc
    Last edited by User137; 28-04-2014 at 12:52 AM.

  4. #4
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    Well, if we're offering code up, there the prometheus code over at http://sourceforge.net/projects/prom...urce=directory though I would HIGHLY recommend waiting for the next update that fixes pretty much everything as the update currently posted has (if I recall) a broken something in every file >.>

    The problem being that the version I work on is for the ongoing UAV project, and as a bad coder I end up messing with the whole thing to get it to behave just so... So if anyones going to be interested in it, give me a heads up and I'll pull the latest source from that project, fix it and post
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  5. #5
    PGDCE Developer
    Join Date
    Oct 2011
    Location
    Blumenau/SC, Brazil
    Posts
    17
    That's just my two cents.


    Code Style:



    License:
    • MIT (It's simple!)


    Compilers:

    • Delphi XE2 Up
    • FreePascal Trunk 2.7.x (Dotted unit)


    I think we shouldn't support old delphi compilers. That way we can focus on the engine and make it simple, without a lot of ifdefs.

    Graphics API:
    • DX 7 Up
    • OpenGL 1.1 Up
    • OpenGL ES 1.x Up


    It's not hard to support these versions with a good engine structure. Initially we can add only OpenGL and later others.

    Sound API:
    • OpenAL
    • DirectSound


    Engine Structure:
    • Abstracts
      • Bitmaps
      • Canvas
      • Device
      • Provider (Graphic API)
      • SwapChains/Context
      • Texture

    • Factory
    • Types
    • Utils (Color, Math, etc)


    It's something like Asphyre structure, imo, it's the way to go.

  6. #6
    It should support both 2D and 3D graphics, right?

    About license: I suggest using Free Pascal license http://wiki.lazarus.freepascal.org/licensing

    Also check out this library: "United Open-libraries of Sound. United procedures for open-source audio libraries. For FPC & Delphi.": https://github.com/fredvs/uos/

  7. #7
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    I mostly agree with Cestari on this but I would do something more like:

    fpc 2.6.4 support primarily, 2.7 for extended funtionality (extra bits and pieces)
    DX9 and up, OGL 2.1 with extensions and up (we at least want FBOs right?)
    As for the enigne structure, I think I'd like to see more suggestions on this as I know there will be most likely be a different proposition from every individual and each will have their own reasons. I'll spare everyone the time to read my own thoughts as I wouldn't consider myself an expert in this domain.
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  8. #8
    Take a look at this library: http://code.google.com/p/la-pe/
    It is a scripting engine for FPC & Delphi
    Supports Pascal-like syntax, but no classes, it seems

  9. #9
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    Now thats quite pretty... It is lesser GPL code but surely theres some way we could fork that and improve it a bit to better suit our purposes if we wanted to...
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  10. #10
    Nice, but I have an objection. For scripting we must adhere to what's standard, sure we can write scripts in pascal alike, but Lua is predominant. Also was thinking about DX and OpenGL, my propose is to have an independent engine with external renders for graphics, same for audio.

    The other thing that's floating in my mind is: are we going to make an embeded engine or a dynamic library? the first is good for pascal developers, the second is good for everyone. Remember, the spirit of this work is to compete pear-to-pear with other engines, so it is mandatory that we don't preset limits to it.

Page 1 of 4 123 ... LastLast

Bookmarks

Posting Permissions

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