My my what an interesting engine, There is only one script so far, but it looks pretty cool so farm I am awaiting greatness.
How exactly would we make a script of our own? Or perhaps, get back to the start once the start script is over? This looks interesting, I really wanna try this out
What I have in mind for now would be a special "menu" file where the game creator could set up the menus they want and a link to the first level. At the moment the solution is to use the "start" option in config.ini. Its value contains the name of the level which should be launched when you press Play, so you could set it to "start mylevel", and when the game is launched 'mylevel.level' will be played
Oh, Ha ha, old chap!, I found out how to make stuff, quite interesting stuff really, you might wanna type your tutorial out on one page so its easier to read, I found a hard time trying to follow it.
Yeah, I admit it's quite hard to read, although it's a bit easier if you use a rich editor and use Assembly colours. I made this in a rush, but I'll definately make a much more clearer documentation
Oh yeah, and one more thing, make a bullet function so you can fire the bullets at an angle, setting the position of the bullet is a bit difficult to make patterns.
Sure, I'll make sure it's implemented
I plan to implement a lot of "shortcut" functions using the more simple ones, and I'll allow user-defined functions as well. There will be functions which simply call a lot of simple ones, like spawning a circle of objects or clone_m which simply calls a lot of 'clone' in a single instruction, functions which manage the boring stuff for you such as the spawn function which make sure objects are loaded and cloned (although it's more efficient to do this before, but I'll explain that in a tutorial later ^^') or functions which allow more complex tasks to be performes (such as curb motions).
I'll spend a lot of time implementing a lot of them as soon as the core of the engine is ready
And could you perhaps, make a diagram of the cords? I tried using middle.x and middle.y and the enemies ended up going up the screen.
A Danmaku made with objs, interesting.
Uh, I'm not sure what kind of diagram you want?
You mean something ike this?
start.x;start.y ----> middle.x;start.y ---> end.x;start.y
|
|
v
start;x;middle.y
|
|
v
start.x;end.y
... etc. ?
I checked again middle.x and middle.y, it worked fine. You can send me your script though, I'll check it to ensure it's not a bug
Can I officially call myself a trend-setter yet? :V
Hehe, actually I had already decided to make this project before looking on the Internet... I was amazed how many similar projects had started just a few weeks before ^^'
I took a quick download and tried it out. Here are my thoughts - please keep in mind this is just meant as constructive criticism ... I'm not trying to insult you or anything.
Don't worry, that's what I'm looking for. And I'm happy I can receive some comments from you since your project is much more advanced than mine
The program had unplayably bad performance in-game. The render rate was fine but the processing rate was low, something around 17 fps if I remember correctly. Now, to be fair, my laptop is fairly weak, so this might be something that is not much of a concern. At the same time, though, do note that Danmakufu (the current "standard" danmaku scripting program around here) as well as my own up-and-coming project Musuu no Danmaku both run decently on the same laptop, so your program probably has some things that could be optimized once it's further developed.
I don't think it's related to optimization, actually my program is already quite optimized except for collisions and garbage collection, so it should run perfectly unless you spawn a lot of bullets (they are marked as 'out' by the garbage collector and not displayed anymore, but they're not erased at the moment and the bullet array becomes too big. I'm pretty sure it's related to your next comment:
Related to this, based on the separate render and "script processing" frame rates, I guess you don't have any strong coordination between the two threads. This can lead to some bad situations - for instance, one thread might eat up the processor time, leaving the other falling behind.
I think that's what's happening here, I developped and tested on dual and quad core CPUs. With a normal script (i.e. not too many objects), the CPU consumption is quite low, but I did something to ensure maximum stability of the internal framerate which might cause serious performence issues on single-core processors, I'll have to emulate one and fix this. Thanks for reporting
However if you're interested: I made the 2 threads as separate as I could, and there are some securities regarding CPU consuption:
- The internal thread which runs at 60 FPS looks if it the actual refreash is happening before of after the theoritical frame and stocks that in an accumulator, once the accumulator is big enough to make one more frame, it will be calculated. This means that if something eats the CPU for a few seconds, the program will try to quickly re-calculate everything so the simulation will appear not to have stopped.
- The rendering thread calculates the time between the currect time and the time of last theoricitical frame. It then proceeds to a linear interpolation of all the coordinates between the last displayed position and the next position which is already calculated but not displayed. If something lags in the simulation FPS, the object will keep moving linearly.
You can clearly witness both of these if you run the game windowed and click to move the window. It'll stop the main thread but not the display thread, so you'll see objects continuing with their current inertia, and once you stop clicking they'll all go to their normal position.
Of course this is all protected with mutexes to ensure coherence. I'll have to check how it works on a single CPU since you've reported troubles, I think I'll add an option to disable multi-threading.
]I must note that there are some media that no credit was given for (the font files, the music files, etc.). If they aren't your own creations, you should make sure it's okay to distribute them like this, and list the original creator of the content. It's generally considered polite to do so, and if you're distributing copyrighted materials that are not allowed to be distributed freely, you could get into trouble.
I'm not trying to dissuade you from using items like this, I'm just saying that you should make sure you've got your bases covered.
You're right, those files are only placeholders I found on my HDD, I wanted to give credits but I couldn't remember the sources. I had planned to replace them, but I didn't find time yesterday. I really wanted to release it since I probably won't be able to code until July (exams
), so I thought it'd be okay if it's just for the very first demo that almost nobody will see... I'll make sure it's replaced though
When closing the program, I did get a crash like you mentioned in your notes. The message was:
The instruction at "0x6b6252ba" referenced memory at "0x0124ef88". The memory could not be "read".
Yup, it comes from the library I'm using (SFML2), I'm not the only one experiencing this issue. It's still being investigated and may be related to the OS I compiled the DLLs on... I'll have to check this out and see if I can fix this :?
I highly recommend having a readme.txt file in the main directory of the program, which lists the basic how-to of getting the program started as well as necessary information such as controls.
I'll write a full documentation, and maybe make a little website. I didn't have time to do much more, and since it's still a complete work in progress it wouldn't be worth it at the moment. But yeah, I should have included a readme, I'll do this for the next release
I find it interesting that you exclude players from being classified as an object. Was there any particular reason for that?
Musuu no Danmaku takes a similar, object-based approach, but it also has the player sprite itself as an object. The advantage of this is that you can then use all of the same scripting methodology for everything in the game.
I have tested your Musuu no Danmaku, but I haven't looked at the scripting part though, so I assume that by "player scripting" you mean what I'd call "attributes" like shot type, image, etc.
In my Danmagine's sources, I have an Object class and a Player class, both of which inheritate from an abstract Entity class. Howevery, in scripting, object-management is closely related to motions and actions (objects don't even have a precise "shot type" at the moment. I really can't use the same code I use for interpreting .level and .object files to interprete a "Player" file, but I'll make sure the scripting syntax (which is completely separated from the actions that are produced, it's actually scanned and translated in a list of internal instructions for every object type, and all objects of the same type simply retain where they are in this list of instructions) remains the same.
While on the topic of scripting, is the script language you're creating based off of anything? I haven't seen a language that looks like this (at least not that I can remember), and it's quite the contrast compared to the C-style syntax seen in Danmakufu and such.
Yeah, at the moment you could say that it's a bit inspired by Assembly language. It keeps this idea of 1 line = 1 instruction which is defined by an instruction code followed by its attributes. I think the main advantage of this kind of langage is that it's easy to understand, easy to do and reasy to read, although you're limited to simple instructions and it gets messy when using more complex ondes. However, simple Danmagine instructions will already perform some complex tasks such as moving in curb motion, so for most tasks you shoudln't need a more complex syntax.
However, Assembly gets much more complicated when you have to make loops, functions, etc. For this kind of instruction, I'll add some C-like syntax, although simplified if I can.
The rest (like separated blocks using %actions -> %endactions) isn't based off anything, I just found it elegent, efficient and easy to implement at the same time.
This is a really minor thing, but I would recommend, for future releases, that you name your .zip file something a bit more descriptive than "release.zip". It'll make it easier for people to find it on their computer, and also give them confidence that they have downloaded the right file.[/li][/list]
Oh, good idea
Out of curiosity - what are you using to implement this program?
I'm programing it in C++ with the Code::Blocks IDE using minGW 4.4 to compile it. My graphics library is the new but awesome
SFML2. It's both more powerful, and easier to use than the SDL. It also has a very active and growing community, and best of all it's really easy to contact the developper (Laurent Gomila) both in English and in French (my mother tongue) for support in case there is a problem or it's missing some functionality. I also use some boost libraries for string operations and muparser which allows me to handle easily mathematical operations (I first wanted to make my own parser, but I it wasn't a very good idea to reinvent the wheel so I choosed to use it and concentrate on the engine itself
)
Overall it looks like a pretty good start (well, what I could see of it, anyways). Keep at it!
Thanks for all your comments, I grealty appreciate it
I only started like 3 weeks ago, and it's my first project in C++ and object oriented (I used to make website applications in PHP and some scientific calculation programs in MATLAB before that, it's quite a change ^^'), so it's all work in progress, but I look forward to this summer so I can really start programming this (?w?)