Prometheus Development Thread

[dazappa]

Looks good, but why create an SDL wrapper? Do you find the wrapper increases your productivity?

[code_glitch]

Its aimed at newbies to help them grasp the concept of how programming works and not work with some abstracts and complexities of sdl and audio directly aong with input and event handling and etc... Ie. the hard part in my learning sdl experience.

[WILL]

I've made a game library/engine myself way back in the day called the Pascal Sprite Engine. Wonderful name, I know. You can probably still find it out there somewhere. It was for Turbo Pascal 7 and it followed a few basic rules as far as functionality and features went. I kept the entire unit structure like a 'black box' you had a list of functions that did everything for you and you didn't have to dabble indie of it or deal with other complicated libraries or functions to make games with it.

I assume that your goal with Prometheus is about the same?

[code_glitch]

pretty much. My aim is based on the fact that when you start pogramming you must think about:
-How the engine/program works
-What the program does
-And how it achieves that

then you need to get that into the relevant code which isn't always too easy/intuitive. (Based on my experience) and sometime you don't know if its the design or the way its done that's giving unwanted behaviour. It's a horrible feeling as a beginner.

The aim of Prometheus at present is simple: Make the translation into pascal as easy and intuitive as possible so that the programmer only has to worry about what matters: understanding how to build programs so that he/she can move onto full on sdl/opengl easily knowing that the way they do things is good and that it works.

I don't know if the above is too clear, and if you don't get it too well, feel free to ask again. Its around 11PM here and I'm really tired...

cheers,
code_glitch

[WILL]

I believe that once the coding gets mature, the documentation, tutorials and demos will be a must for the first release. I'm sure others will like this idea and want to help, maybe make a few simple demos. Documentation should be easy to read and follow. Keep it as simple as the library to use, yet detailed enough so that they understand all the aspects of your library. This of course will take time. More time than it will take to make the library it's self I'm sure.

[code_glitch]

Again, a slight update: added a google code project for prometheus here: http://code.google.com/p/prometheuslib/


Also, WILL asked a valid point about how library management works as I didnt explain it in my last blog post, heres how:
you have an array of objects each with:
The data (eg fonts, image)
Name
Boolean whether its used or not
and any extra data.

Then when you call load_whatever(name, source) it loads that into the next empty slot in the array. To process it you simple do process_whatever(NAME) and it checks where it is in the array and does it for you. Its not always the most efficient, however.

Hopefully that clarifies things as to how I would implement a library s such.

Furthermore, all Prometheus updates will be posted here and links to the code on google code also.

cheers,
code_glitch

PS: Also made a small graphics update retro style. Although it should no longer be called probewars, it looks a ton better now...
The download links are here: http://code.google.com/p/prometheuslib/downloads/list
The homepage is here: http://code.google.com/p/prometheuslib/

[code_glitch]

Yet another new feature that I was suggested in RL which I might deem feasible: character rendition engine and map rendition engine based on TileD csv along with tileset management built into Prometheus. Although I do plan on adding such functionality, would you prefer it as part of the Prometheus_Vid unit or would it be worth creating a Prometheis_Spec unit?

Cheers,
code_glitch