Author Topic: Danmagine [Danmaku creator] - 08/04/12: v1.2 - Alpha2  (Read 28116 times)

Danmagine [Danmaku creator] - 08/04/12: v1.2 - Alpha2
« on: May 12, 2010, 09:22:25 PM »
Danmagine

Version: v1.2 - Alpha 1
Download & information: See here



______________

Description: Danmagine is a new game engine especially made for easily creating Danmakus (i.e. shoot'em-ups with a hell lot of bullets). The main goal of this project is to allow anyone to make the shoot'em-up they want, whether it is a simple shoot'em up level or a complete game which requires advanced patterns and efficient objects management. Danmagine should not require any programming skills, what's needed will be learnt through the tutorials.

Danmagine relies on a core program extended by a scripting language. This scripting language is designed in such a way that it allows you to perform usual yet complex tasks in a single instruction while providing you lots of tools to go further. It is also designed with modularity in mind: most of the game logic is exposed to scripting, allowing you to tweak the engine's behaviour at will. Instead of modifying it, you can also extend it by using the libraries: design your own library and add it to your project in a clean way.

In Danmagine, everything is scriptable and you're provided what you need to do it. Menus, levels, sounds, musics, player, enemies, decor, everything can be done your way using functions, attributes, events, tasks and all the other tools and structure you have at your disposal.

The engine is constantly and rapidly improving. If you feel something's missing, just ask. It'll probably appear in the next version.
« Last Edit: April 08, 2012, 01:13:10 PM by Mjonir »

Re: Danmagine
« Reply #1 on: May 12, 2010, 11:16:37 PM »
=o


Interesting, Im downloading this and I will have a review later

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

Oh, lol, 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.

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. 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.
« Last Edit: May 13, 2010, 12:10:41 AM by Demonbman »

Nuclear Cheese

  • Relax and enjoy the danmaku.
    • My homepage
Re: Danmagine
« Reply #2 on: May 13, 2010, 02:12:08 AM »
Can I officially call myself a trend-setter yet? :V



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. ;)

For what it's worth, I'm on my laptop, with specs as such:
1600Mhz Intel processor
512MB RAM
256MB ATI video card
1400x1050 screen

Ran the program with default configuration.

  • 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.
    • 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 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.
  • 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".
  • 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 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.
  • 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.
  • 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.
  • Out of curiosity - what are you using to implement this program?

Overall it looks like a pretty good start (well, what I could see of it, anyways).  Keep at it!
to quote Naut:
"I can see the background, there are too many safespots."
:V

Re: Danmagine
« Reply #3 on: May 13, 2010, 01:06:53 PM »
    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 :P

    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 :P)

    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?)
    « Last Edit: May 13, 2010, 04:59:41 PM by Mjonir »

    Re: Danmagine
    « Reply #4 on: May 30, 2010, 08:40:06 PM »
    Hi again, I improved my engine (collisions, player scripting, work on sounds, CPU consumption, framerate stability, ...), but not that much because of my exams. I'm about to completely re-implement the scripting so it'd be pointless to release something right now, sorry :P

    I'm just here to ask: Would anybody have some shotsheet / sprites / sounds / musics I could use in my demo scripts (with proper credit of course :))? Anything will do, although I'd obviously prefer something that looks/sounds nice (^-^)

    Re: Danmagine
    « Reply #5 on: November 03, 2010, 07:23:14 PM »
    Hi everybody,

    This isn't a new release yet since it's not stable, but I couldn't wait to show you what I've done. Basically I've reached the point where everything you see is 100% scripted and easily scriptable.

    Right now there are major bugs, a lot of space for improvement both on the engine and the support for scripting (including lots of syntactic sugar) and missing features, but it works and I think it's a pretty big step.

    Download here!

    Since it isn't stable yet,, I didn't have much time to make a real demo or tutorial or any kind of documentation so if you want to have fun with the engine you'll have to figure it out yourself, or ask, but I think it's already pretty easy to manipulate once you've got the hang of it.

    I strongly suggest you have a look in the "objects" folder, where most of the script lies. You can also have a look at "*mask.lua" files in the "lua" folder if you want to know what you can do with the engine (it'll soon be able to do much more, that's the easy part :)).

    So, in a few words, what's different from v0.1?
    • Mainly a whole new, and much more powerful, scripting language using Lua as a basis. Very easy to use, even for a non-programmer, and powerful at the same time. Have a look inside the "objects" folder to see what I mean.
    • Collisions (use "display_hitbox = 1" in config.ini if you want to have a closer look :))
    • Sounds and music (although there is no play_music() function yet, believe me when I say that it works :P)
    • Much better CPU consumption ans stability
    • Player scripting including shots and bombs
    • Menu scripting
    • Better performances and smaller size
    • A lot more scripting possibilities.


    Have fun. I hope I'll be able to release a stable version soon, with even more possibilities on the scripting side :)

    rfw

    Re: Danmagine
    « Reply #6 on: November 06, 2010, 03:58:14 AM »
    Mandatory "I hope you're making this open-source", "oh god why are you using Lua" and "oh god why are you using C++".

    Also >boost fsadfsahgljdsaghdaasgjdsgkljsafhlf ENJOY YOUR SCREENS OF TEMPLATE ERRORS

    That aside, performance is pretty good -- at roughly 3600 bullets I get 20fps; there's room for improvement (doubtful anyone would need upwards of that many though), and I suspect the overhead is from the Lua interpreter. My test case:
    Code: [Select]
    while true do
        for i=-180,180,0.1 do
            shoot("ebullet", i)
        end
        wait(2)
    end

    You have one thread for rendering and others for updating -- there don't seem to be any timedelta values provided to the scripts, so wouldn't they desync? Or are you mutexing them so they synchronize? Avoid any blocking synchronization measures since that inhibits performance. Also, a... a... garbage collector thread? In C++? Blasphemy! Just deallocate everything, carefully...

    More on multithreading -- have you considered using a worker pool to allocate tasks? Realistically, nobody uses threads for specific tasks any more and it's often more profitable if you use a producer-consumer-based approach, as it will often alleviate the need for mutexing and other forced synchronization. Couple this with coroutines (i.e. replace your wait function with a yield) and you may get better performance.

    Nonetheless, keep up the good work! I probably won't be using this!

    EDIT: WHY DO YOU PEOPLE USE MINGW-GCC GO USE GODDAMN MSVC++
    « Last Edit: November 06, 2010, 04:24:07 AM by rfw »

    bennelsey

    • Touhou fan-game Developer
    • Will make Touhou fan-games for food
      • EastGap
    Re: Danmagine
    « Reply #7 on: November 06, 2010, 09:09:03 AM »
    so i found that it really errors alot on my pc at around 300 bullets, so i took the liberty of trying to take a good screenshot while getting the error:
    http://img155.imageshack.us/img155/6797/teherror.png
    not really sure why it does that, can't seem to link the error to something specific and the pic was (finally) taken when it somehow got to 1000 objects without breaking

    So anyway, i see that the menu runs at 60fps but the game with few objects runs at about 30fps, must be the lua thing. Have you tried frameskipping instead of multi threading?

    Hell it's prolly the fault of my comp to begin with, it can't handle any of the official Touhou games at anything more than 30fps, but with a blank background i woulda expected something faster on this forsaken computer ^^

    Re: Danmagine
    « Reply #8 on: November 06, 2010, 01:03:26 PM »
    Mandatory "I hope you're making this open-source"

    The engine should be free and open source, but I'll see when the code will be cleaner with comments and everything... I'd feel ashamed right now :blush:

    If you want to look at any specific part I can upload it though, but beware of the mess and un-optimized code :p

    Quote
    "oh god why are you using Lua"

    I started making my own little language, but I felt like I was reinventing the wheel. Moreover, with Lua a larger part of the engine is open to customization because you can edit all the .lua files freely. I thought about using Python, but Lua just seemed more appropriated. It allows me to provide a lot of scripting possibilities that'd have taken a lot of time to implement from scratch, and overall it works really better.

    And apart from my own language, the resulting syntax for scripting couldn't really have been better in my opinion.

    Why would I use anything else? :p

    However there's a lot of abstraction between the engine and Lua. As you've maybe seen if you've looked at *mask.lua files, everything is going through a LuaInterface object so in the future it'd be possible to allow other scripting languages, I'd only have to replace LuaInterface with YourFavouriteLanguageInterface :p

    Quote
    and "oh god why are you using C++".

    As opposed to what? :o

    Quote
    Also >boost fsadfsahgljdsaghdaasgjdsgkljsafhlf ENJOY YOUR SCREENS OF TEMPLATE ERRORS

    It's hard to get it to work, but when it does it does the job very efficiently :)

    Quote
    That aside, performance is pretty good -- at roughly 3600 bullets I get 20fps; there's room for improvement (doubtful anyone would need upwards of that many though), and I suspect the overhead is from the Lua interpreter.

    I don't know where the bottleneck is, but I doubt it's in Lua. Lua is pretty fast, and there are a lot of places where my code could be optimized. For example, collision detection could be easily improved (at the moment it's a brute force where all bullets try to detect if their hitbox collide with the player's).

    If the problem is indeed in Lua, then it's probably my fault because I'm asking it to re-compile update.lua, levelmask.lua and objectmask.lua every frame. Again it's a simple improvement that could be done, and it will be done, but there are hundreds of things like this. Once it's bug-free and has a minimal amount of possibilities, I'll ensure performances increase drastically :)

    Quote
    You have one thread for rendering and others for updating

    Actually it isn't true in this alpha release. There wasn't any abstraction between my own language and the engine so when I had to remove it, I really had to tear it apart. I thought it'd be a good occasion to reorganise the code as well, so I disabled multi-threading for the moment. It's still there, but it's not active, I'll activate it again when current bugs are solved. Perhaps I'll even make it optional, so that you can decide to use it or not :)

    However there might be a misunderstanding, there is only thread for display and one "main" thread for updating. Other threads are non-blocking operations, such as "garbage collection" (more info on that below)

    Quote
    -- there don't seem to be any timedelta values provided to the scripts, so wouldn't they desync?

    I'm not sure what you mean. If you look inside "update.lua", which is single Lua file that's called every loop from C++, there is:

    Code: [Select]
    DMG["elapsedTime"] = LuaInterface:getFrameTime()
    This function returns time elapsed since the previous frame. "getElapsedFrames()", which returns the number of frames since the game launched, and "getElapsedTime()", which returns the amount of time since the game launched, also exist.

    Quote
    Or are you mutexing them so they synchronize? Avoid any blocking synchronization measures since that inhibits performance.

    Since it's not in the current release, I'm still unsure how exactly it'll work with the new code. But the way I see it, there is no need for a strong synchronization between display and simulation. Simulation updates the game without worrying about how it has to be displayed, and Display shows the game as it is, without worrying about how it's updated.

    Or do you think that all objects are run in separate threads? They're not, they're coroutines (more on that below) :)

    Quote
    Also, a... a... garbage collector thread? In C++? Blasphemy! Just deallocate everything, carefully...

    No, no, no, it's not that kind of garbage collector. When an object (a bullet, an enemy, everything) dies, it's just flagged as "Out". As a result, the main update thread will simply skip it when it appears so that it won't be displayed nor interacted with.

    The garbage collector is a separated operation every frame that checks all objects to see if there are any with the "Out" flag. If there is, it removes them properly from the game :)

    Quote
    More on multithreading -- have you considered using a worker pool to allocate tasks? Realistically, nobody uses threads for specific tasks any more and it's often more profitable if you use a producer-consumer-based approach, as it will often alleviate the need for mutexing and other forced synchronization. Couple this with coroutines (i.e. replace your wait function with a yield) and you may get better performance.

    From what I read, it looks like you think all objects are running in separate threads. But all this runs in a single Simulation thread. Here's how it works:

    C++ runs and looks where he is and treats inputs. If he's in the game section, C++ asks Lua for an update.  Lua resumes the level coroutine, then asks its task manager for an update with Manager:update(). The manager then launch/resumes all objects coroutines (If you want to see how it works, it's all in the "manager.lua" file :)). When everything is done, C++ resumes and checks for collisions, etc. and eventually displays. There is no need for any mutexing :)

    The wait() function in the scripts is already a yield:
    Code: [Select]
    function wait(length)
    DMG_OBJ[DMG["currentObjId"]]["wait"] = length
    coroutine.yield()
    end

    DMG_OBJ[id]["wait"] is then decreased by the task manager by the amount of elapsed time, and when the wait is over the coroutine resumes.

    Quote
    EDIT: WHY DO YOU PEOPLE USE MINGW-GCC GO USE GODDAMN MSVC++

    Well, GCC works and I've already been asked for linux ports :)

    Quote
    Nonetheless, keep up the good work! I probably won't be using this!

    Thanks a lot for the reply, it's really nice to have some feedback. I hope I didn't kill you with my long answer :p


    so i found that it really errors alot on my pc at around 300 bullets, so i took the liberty of trying to take a good screenshot while getting the error:
    http://img155.imageshack.us/img155/6797/teherror.png
    not really sure why it does that, can't seem to link the error to something specific and the pic was (finally) taken when it somehow got to 1000 objects without breaking

    I'm pretty sure it's not related to the number of bullets. It's a known bug with the left slime. I don't know why yet, but when you kill it there's a slight chance that the game crashes :?

    More specifically, it's related to the "mover" object spawned by the slime to make it move while it shoots. It's n?1 of my list of bugs to solve, and should be fixed soon :)

    If you comment out or remove the "mover" (line16 in slime.object), you shouldn't get any crashed apart from audio abuse (the sounds stop playing if you use them too much, I don't know why yet, but the game doesn't crash). Nevertheless if it still crashes after that please tell me? I'd be very interested :)

    Quote
    So anyway, i see that the menu runs at 60fps but the game with few objects runs at about 30fps, must be the lua thing. Have you tried frameskipping instead of multi threading?

    In the previous version I used frames as the basic measurement of elapsed time, and tricked the engine into working at 60FPS fixed... Now everything works with real elapsed time so that the result is more stable. In the previous version if the game was over-budget for one frame, for example if one frame took twice the maximum time, it'd have had to calculate 2 frames at once in the next loop, which was fine if was an isolated problem, but otherwise it'd accumulate on slower computers. In the current version it doesn't matter if the games runs at 20FPS instead of 60, the objects will be moved proportionally to the elapsed time.

    The work done on the engine to get it work at a fixed 60FPS won't be lost though, I'll activate it again to that the result is even smoother.

    Quote
    Hell it's prolly the fault of my comp to begin with, it can't handle any of the official Touhou games at anything more than 30fps, but with a blank background i woulda expected something faster on this forsaken computer ^^

    I'm both surprised and not at the same time. Like I said somewhere above there's still a lot of optimization to come, and the final result should be way better. But I'm surprised if you tell me that you're at 30 FPS with the script I included with the engine? Apart from when you shoot, there's not a lot of calculation involved. I guess it must be Lua compiling its files every frame... but even on my laptop the game doesn't eat much CPU :o

    Can I ask what your specs are? Could you check if it's really the engine eating 100% of your CPU?

    Thanks for the feedback on this! :)

    bennelsey

    • Touhou fan-game Developer
    • Will make Touhou fan-games for food
      • EastGap
    Re: Danmagine
    « Reply #9 on: November 06, 2010, 02:40:04 PM »
    But I'm surprised if you tell me that you're at 30 FPS with the script I included with the engine? Apart from when you shoot, there's not a lot of calculation involved. I guess it must be Lua compiling its files every frame... but even on my laptop the game doesn't eat much CPU :o

    Can I ask what your specs are? Could you check if it's really the engine eating 100% of your CPU?
    2.4GHz Intel processor
    2GB Ram
    256 MB GeForce FX 5500 video card
    1024 x 768 resolution

    yep, 30fps with the default script and eats about 11% CPU at that frame rate

    ...oh lol i thought that second number from the top was the number of objects
    (and it maintains that even at 700+[second number] , couldn't reach any higher though cuz of that error i pointed out)

    well i commented out that mover line 16 and since no slimes appear, no bugs would appear either \o/ (lol jk)

    Re: Danmagine
    « Reply #10 on: November 06, 2010, 03:11:08 PM »
    2.4GHz Intel processor
    2GB Ram
    256 MB GeForce FX 5500 video card
    1024 x 768 resolution

    yep, 30fps with the default script and eats about 11% CPU at that frame rate

    It should be more than enough, and it doesn't look like it's the game eating too much CPU.

    Vsync in enabled by default (you can disable it in config.ini with "window_vsync = 0"), it locks the maximum number of frames per second on your screen's refresh rate. Perhaps your screen resolution is locked at 30hz? If not, does disabling vsync gives more FPS?

    Quote
    ...oh lol i thought that second number from the top was the number of objects
    (and it maintains that even at 700+[second number] , couldn't reach any higher though cuz of that error i pointed out)

    well i commented out that mover line 16 and since no slimes appear, no bugs would appear either \o/ (lol jk)

    Oh, no, it's the number of elapsed frames since the game launched (used it for debug purposes).

    Are you sure you commented the line properly (In lua a comment starts with "--")? Because with just this line commented out, both slimes should appear and the only difference would be that the left slime wouldn't move.

    Scripts are called in protected mode so if you did a syntax error, the script simply won't run (I didn't have time to add a proper warning message in the console yet), but the rest of the game will be unaffected, which looks like what you did? :p


    EDIT: Oh, you also have to change:
    Code: [Select]
    onDeath(function () die(mover); shoot("powerLife"); spawn("spawnNewSlime") end)

    into

    Code: [Select]
    onDeath(function () shoot("powerLife"); spawn("spawnNewSlime") end)

    Otherwise it'll crash when the slime is killed because the die() function, being passed no real argument will default to asking C++ to kill the slime... which it what he's already doing, resulting in an infinite loop between C++ and Lua.
    « Last Edit: November 06, 2010, 08:23:44 PM by Mjonir »

    rfw

    Re: Danmagine
    « Reply #11 on: November 06, 2010, 09:59:06 PM »
    My eyes bled a little from reading that wall of text, but otherwise I'm fine.

    Anyway, since you seem want an object-oriented approach to scripting, then why not use an object-oriented language? I agree Python is pretty fuckawful to embed in programs at a low level, and boost::python isn't all that fun either. You could try Falcon -- an actually object-oriented language which I hear is a pretty awesome programming language to embed (never used it personally, though) -- and can be faster than Lua in some cases.

    I didn't notice that elapsed frame time counter in update.lua, heh (I was expecting it to be in a function signature, like function update(dt). Maybe that's a case of too much XNA).

    And yeah, it looks like I've totally misinterpreted your use of threading (orz). Still, a threadpool would be nice :3
    « Last Edit: November 06, 2010, 10:21:41 PM by rfw »

    Re: Danmagine
    « Reply #12 on: November 06, 2010, 10:41:41 PM »
    My eyes bled a little from reading that wall of text, but otherwise I'm fine.

    Heh, sorry, I'll restrain myself this time :p

    Quote
    Anyway, since you seem want an object-oriented approach to scripting, then why not use an object-oriented language? I agree Python is pretty fuckawful to embed in programs at a low level, and boost::python isn't all that fun either. You could try Falcon, which I hear is a pretty awesome programming language to embed (never used it personally, though) -- and can be faster than Lua in some cases.

    Oh, actually you can do object-oriented in Lua. It's a bit special, but it works nicely. Objects in Lua are tables receiving information they don't have from a metatable. It's a bit complicated to represent, but I found a nice code ("class.lua") which is a nice wrap of that metatable stuff. You can see an example of object-oriented in "vector.lua", it's a custom definition of "vectors" used for about anything that uses 2 components.

    I didn't know about Lua before using it in my engine so I don't have enough experience yet, but when I do I'll simply move all the "flying" functions in *mask files in classes :)

    Also I think it's important not to use a fully object-oriented scripting language, as it is more complicated in my opinion for non programmers.

    About embedding, I'm using the excellent luabind. The only complex stuff with Lua is all those stack manipulations. Actually I don't even know about them, I never read this part of the documentation, because thanks to luabind all I have to do is say "I want a class like this in Lua, and in it i want all those functions", and it's done!

    See how it's used in C++:

    Code: [Select]
    module(L) [
                class_<Lua_interface>("Lua_interface")
                    .def(constructor<>())
                    .def("printC", &Lua_interface::printC)
                    .def("getState", &Lua_interface::getState)

                    .def("getElapsedTime", &Lua_interface::getElapsedTime)
                    .def("getElapsedFrames", &Lua_interface::getElapsedFrames)
                    .def("getFrameTime", &Lua_interface::getFrameTime)

                    .def("playSound", &Lua_interface::playSound)

                    .def("player_image", &Lua_interface::player_image)
                    .def("PlayerCoord", &Lua_interface::player_getCoord)

                   ...

                    .def("menu_setNext", &Lua_interface::menu_setNext)
                    .def("menu_setPrev", &Lua_interface::menu_setPrev)
                    .def("menu_setRight", &Lua_interface::menu_setRight)
            ];

    Quote
    I didn't notice that elapsed frame time counter in update.lua, heh (I was expecting it to be in a function signature, like function update(dt). Maybe that's a case of too much XNA).

    I could have done this, but I prefered to run a specific file so that if you want to add other stuff during the update I think it's cleaner this way.

    Quote
    And yeah, it looks like I've totally misinterpreted your use of threading (orz). Still, a threadpool would be nice :3

    You mean this?

    I agree, it might be a nice optimisation in the future. It wouldn't change the way I do things nor remove possibilities, just make it faster. I'll note it somewhere, when I'll be at the point where the engine is complete enough for optimisation I'll see what I can do, thanks a lot for the suggestion :)

    bennelsey

    • Touhou fan-game Developer
    • Will make Touhou fan-games for food
      • EastGap
    Re: Danmagine
    « Reply #13 on: November 07, 2010, 12:02:20 AM »
    It should be more than enough, and it doesn't look like it's the game eating too much CPU.

    Vsync in enabled by default (you can disable it in config.ini with "window_vsync = 0"), it locks the maximum number of frames per second on your screen's refresh rate. Perhaps your screen resolution is locked at 30hz? If not, does disabling vsync gives more FPS?
    it's locked at 60Hz ^^
    disabling vsync gets me to 40fps during the game now \o/

    *properly* commented line 16 this time and changed the ondeath function but i still got error'd :/
    http://img191.imageshack.us/img191/8194/teherror2.png
    (yeah i did a C++ styled comment earlier lawl)

    Re: Danmagine
    « Reply #14 on: November 07, 2010, 10:17:53 PM »
    it's locked at 60Hz ^^
    disabling vsync gets me to 40fps during the game now \o/

    If you get better performances without vsync and the CPU isn't overloaded, perhaps it's the GPU that's overloaded? :?

    What happens if you disable AA?

    Code: [Select]
    window_AA_level = 0in config.ini, instead of =8

    You might also get better performances in full screen:

    Code: [Select]
    window_fullscreen = 1
    But I still find it weird since nearly nothing is being drawn :o

    Perhaps it's the graphical effects of Windows eating the GPU? :?

    Quote
    *properly* commented line 16 this time and changed the ondeath function but i still got error'd :/
    http://img191.imageshack.us/img191/8194/teherror2.png
    (yeah i did a C++ styled comment earlier lawl)

    That's weird. Could you send me your modified script (PM or mail) so I can have a look and see where the problem is?

    bennelsey

    • Touhou fan-game Developer
    • Will make Touhou fan-games for food
      • EastGap
    Re: Danmagine
    « Reply #15 on: November 08, 2010, 10:58:01 AM »
    What happens if you disable AA?

    Code: [Select]
    window_AA_level = 0in config.ini, instead of =8
    i got 200 fps lol, not sure what that is but it did it

    Code: [Select]
    window_AA_level = 0You might also get better performances in full screen:
    Code: [Select]
    window_fullscreen = 1
    nope no improvement here

    That's weird. Could you send me your modified script (PM or mail) so I can have a look and see where the problem is?
    i was using the default script for this and that last pic
    (the first one was modified though, all it did was change the shooting delay of that slime)

    anyway, it still error'd even with
    Code: [Select]
    -- mover = spawn("moveMySlime",DMG["currentObjId"])
    onDeath(function () shoot("powerLife"); spawn("spawnNewSlime")   end)

    [edit]
    I get 400+ fps in the menu with this and 200+ in-game
    Code: [Select]
    window_AA_level = 0
    i get 200+ fps in the menu and 100+ in-game with
    Code: [Select]
    window_AA_level = 1
    « Last Edit: November 08, 2010, 10:59:51 AM by bennelsey »

    Re: Danmagine
    « Reply #16 on: November 09, 2010, 09:44:16 AM »
    i got 200 fps lol, not sure what that is but it did it

    AA = 0 simply disables smoothing. I'm not using it anyway at the moment, I prefer to round coordinates so that sprites don't have to be smoothed, this usually gives an even better result.

    Since you got way better performances with this, I think it's your GPU which was overloaded or/and handled AA badly. Thanks for letting me know, I'll lower the default setting in future releases :)

    Quote
    i was using the default script for this and that last pic
    (the first one was modified though, all it did was change the shooting delay of that slime)

    anyway, it still error'd even with
    Code: [Select]
    -- mover = spawn("moveMySlime",DMG["currentObjId"])
    onDeath(function () shoot("powerLife"); spawn("spawnNewSlime")   end)

    That's really weird, the code is correct and I have no errors on my computer :s

    It might be related to an already solved bug which was present in the release, under certain conditions an object (such as the slime) would become unkillable. This would also lead to very bad performances if an unkillable bullet escaped far away from the playing area (normally it's garbage collected, but since it's unkillable... :p). Since I have no idea I think I'll solve current bugs and see if it's still present in future releases and/or if other people report the same problem :s

    Re: Danmagine
    « Reply #17 on: December 05, 2010, 07:48:10 PM »
    It's not a release yet but I thought I'd post what I'm doing since it's going to take a while (mid-term exams are approaching :()

    I'm currently making a little website for my engine, you can visit it here: http://mjonir.gantzotaku.com/danmagine/

    There's not much at the moment but I'll be updating it regularly, starting with the 3 tutorials which should be enough for you to start making something nice. It's going to take a while since I've got to make a nice tutorial script with comments everywhere AND explain it even more on the website. However once it's done, it'll be really easy for you to use the engine, you'll just have to follow the tutorial to learn the basic principles, after that it'll be nearly always the same thing, just new functions to use.



    In parallel the engine also improved a bit, tasks are now even better integrated and way more powerful. It's like an easy mini-multitasking for all your objects, without any synchronization worries of course, and it works really well :)

    I'm also adding new options every day, mostly stuff that's already present in the engine that I'm making it available for scripting. I'm also testing everything to catch all bugs I can find. One nice thing I added was a safety layer between the scripting side and the engine side so that the engine won't crash if you're doing something really bad like trying to do something on an object which doesn't exist.

    Also finished submenus in menu scripting. You can now entirely script button and menu structure with a lot of freedom. The only things missing is the more graphical stuff to make your menu pretty, and more importantly allow the buttons to run scripts (so that your menu actually does something :p) but that should be pretty quick.


    I feel like the core of the engine is done now. The only thing I'm doing now is adding new scripting options, some stuff are still clearly lacking such as text objects or animations, but my engine is approaching the "usable" state now :)

    bennelsey

    • Touhou fan-game Developer
    • Will make Touhou fan-games for food
      • EastGap
    Re: Danmagine
    « Reply #18 on: December 06, 2010, 03:46:56 PM »
    Looking forward to this, I'm not sure why and i haven't really tried the other danmakufu alternatives but my gut feeling tells me this has potential :3

    Re: Danmagine
    « Reply #19 on: December 24, 2010, 01:09:00 AM »
    I couldn't resist to tell you: I've stopped writing documentation for a while because instead I decided to complete something I've been putting off for quite a while: Proper layers of drawing including priorities. So what does it mean?

    Before that, the order in which images are drawn, i.e which one appear on top of which one in case they overlap, was determined either by the order in which they were created or by the collision layers (like enemies drawn above players and under bullets). But this wasn't satisfying because it was rather restrictive and I also needed a mean to draw things before everything (background) and on top of everything (foreground/HUD).

    So what I did is create a whole new type of layer, drawing layers, which are very similar to collision layers except they add one layer below and one on top. Actually if you only use basic commands, this whole drawing layer stuff will be automatically handled for you based on the collision layers, like before. What's more interesting is that you can now choose in which layer the image should be drawn, independently from the collision layer, and that you can also set a priority.

    By default, an object has a drawing priority of 0. If two objects are in the same layer and have the same priority, it's just the same as before and they're drawn based on the order in which they were created. However, you can choose a drawing priority which is an number either positive or negative. Objects with higher priority will be drawn above objects with lower priority. For example if you have 3 objects: A (priority 0), B (priority 10) and C (priority -5), B will be drawn above A, and A above C.

    It's a quite simple but very powerful feature, and I had some trouble implementing it (experienced a lot of weird stuff with the priority :/). I'm really glad this is done, because it will now allow me to properly develop stuff I wanted to include in the tutorial like HUD elements (for that you need a proper foreground, and you need to tell the engine that the text should be displayed on top of the foreground image).

    _____________________________

    So, about the upcoming release of a usable version, I'm getting pretty close. There isn't much more to do on the engine itself, I merely have to add dynamic texts for HUD elements and it should be very easy. On the scripting side however I'll have to write a whole neat tutorial, and more importantly make a proper documentation for it. As of today I'll start updating my website again with that content, but since my exam period is approaching it may be quite long to do the whole stuff. I expect to complete the tutorial somewhere in February or early March. I'm really looking forward to this, because that's where the fun part really begins (^-^)/


    EDIT: Oh, btw, if there's anything specific not tooooo complicated you'd like to see in the first tutorial because you're curious about how it should be implemented with my engine, please don't hesitate to ask, I'll include it :)

    _____________________________

    bennelsey -> I hope I'll meet your expectations :)
    « Last Edit: December 24, 2010, 01:17:08 AM by Mjonir »

    Re: Danmagine
    « Reply #20 on: December 29, 2010, 12:09:07 AM »
    Hey guys, finally finished my work on texts and they work great. I also had to do a little bit of debugging with drawing layers, but not much. You know what that means? Beta release time!

    You can find everything on the Danmagine website: http://mjonir.gantzotaku.com/danmagine/

    The beta release comes in 3 flavours: Clean, test and source. Yup, it's officially open-source so the most curious can now browse the engine code and see how it works inside. Be careful though, the code is quite substantial. Don't hesitate to give me some feedback on it (don't forget it's a work in progress though) :)

    Read the news on the website, there is more information there :)

    Don't hesitate to post/email if you've got some feedback to give. Otherwise see you soon once the tutorial is done for a full release (^-^)

    Re: Danmagine (29/12/10: beta + sources released)
    « Reply #21 on: January 07, 2011, 10:09:17 PM »
    Hi again,

    I've got a general question this time: I never tried using Danmakufu so I don't know how much performance it can give? Like how many on-screen objects can it handle without slowing down (let's say <50 FPS? <30 FPS?) on an average machine?

    Since of course it depends on the hardware, could anybody link me to a script that'd be considered "heavy" without exaggerating (and so very badly scripted of course)?

    I'm just wondering if I need to make performance improvements or not before releasing a first version. For the moment I'd say my engine can handle up to 1500/2000 bullets while staying over 30 FPS depending on the hardware. Would you consider that enough for a danmaku or not?

    I could hugely improve performances by re-enabling multi-threading, but it'd need a little bit of work, I'd rather not do that now if it's not necessary :V


    BTW, if anyone is interested, I switched the Danmagine website to MediaWiki + forum format. MediaWiki was the way I was heading anyway so it'll be easier to read, and I was just requested the forum.

    Re: Danmagine (29/12/10: beta + sources released)
    « Reply #22 on: January 07, 2011, 11:58:25 PM »
    I'd suggest going through the contest threads and reading the judges' impressions.  They tend to comment when a card causes slowdown.  For example, Hoppefrosk's entry in the Laser Light Show got this response from Blargel:

    Quote
    Your last attack on the other hand is ridiculously hard, mostly because of how all the other lasers cover the warning laser that two lasers are about to spawn right on top of me. When the whole screen gets covered in that design, my framerate drops ridiculously too. On the plus side, that design is interesting and I wonder how you made it. I'll need to look at your script in the near future.

    http://www.mediafire.com/?dyylmtkncoo

    Re: Danmagine - 16/02/11: v0.2 (full) released!
    « Reply #23 on: February 16, 2011, 02:15:00 PM »
    See the project Wiki for download & tutorials

    Here is the release of Danmagine v0.2. So what can you do with it?

    I'd say almost everything you might expect from it. It is stable, powerful and everything can be scripted. There are lots of tools and a few libraries. On the project Wiki there is a full documentation, with tutorials, and a forum where I'll be happy to answer in case you have a problem. It is a complete and working version, you should not have any problem getting started.


    Then why is it not v1.0?

    Because it needs some polishing. Although technically speaking you should be able to do almost anything you can think of, for some complex tasks it might not be very convenient to do it with the tools you have now. v1.0 will mostly need to have larger libraries. To do that, I need a lot of feedback. Up to now I'm pretty much the only one who used it. As a result, I don't know if what I've implemented and the way I've implemented it is what you will want. Thus, please, don't hesitate to send some feedback on my email or on the forums. Whether its simple remarks, suggestions, feature requests or just general thoughts about the engine, I'd really like to hear them to improve the engine :)


    Have fun scripting (^-^)/

    [tso]link fixed, don't use "s around your URL :V[/tso]
    « Last Edit: February 16, 2011, 04:20:13 PM by ♪ Tesoro Corporation ♫ »

    Re: Danmagine - 16/02/11: v0.2 (full) released!
    « Reply #24 on: March 02, 2011, 05:28:34 PM »
    Hi everyone, no Danmagine news but rather a general question since there are more scripters here than elsewhere:

    If there was a graphical interface, i.e. an application where you would create your game using menus and mouse clicks, which would create the corresponding scripts automatically, would you use it or would you rather code directly?


    I'm asking that because I've found a volunteer to make a graphical interface of this kind for Danmagine. This kind of feature would of could be quite attractive for beginners who are afraid of programming, but as slightly more experienced people in scripting & creating games, what do you think?

    Your answers would be useful in order to determine the kind of public we'd be targeting with that interface :)

    Re: Danmagine - 16/02/11: v0.2 (full) released!
    « Reply #25 on: March 02, 2011, 10:35:48 PM »
    I would totally attempt to use a Graphical Interfaced danmaku maker things, I think that is a good idea, I myself have contemplated the though of how one would work, and I can see how that can have its problems.

    bennelsey

    • Touhou fan-game Developer
    • Will make Touhou fan-games for food
      • EastGap
    Re: Danmagine - 16/02/11: v0.2 (full) released!
    « Reply #26 on: March 03, 2011, 11:32:33 AM »
    yeash, if there was a simple way to make danmaku without typing code even if it'll end up simple and be really limited people will be fine with that
    *cough*likegamemaker*cough*

    then again you said graphical interface instead of a complete development environment lol

    Re: Danmagine - 16/02/11: v0.2 (full) released!
    « Reply #27 on: March 03, 2011, 05:08:44 PM »
    If it's at all possible, I'd much rather have a GUI myself.
    All lies and all sin, all dreams and all majesty, Everything rots in this ruined hell

    [The Perfect, Elegant Maid] [Pathos of the Hated People] [Music, Projects, and Art]

    8lue Wizard

    • Cobalt Magician
    • (Apparently)
    Re: Danmagine - 16/02/11: v0.2 (full) released!
    « Reply #28 on: March 03, 2011, 07:19:58 PM »
    For really complex mathy stuff, there's really no substitute for working directly with the code. Though, I imagine it'd be convenient for making simpler patterns, like most noncards, and especially in making stages.

    ReimuHakurei

    Needs Stage background fixing please
    « Reply #29 on: March 28, 2011, 04:30:07 PM »
    Hi

    Can someone help me with this one problem I tried having a fix at.
    everytime I load the game go to play it crashes heres a picture (also dose not show the background.... and the character)

    http://i300.photobucket.com/albums/nn10/Callammutton/Error-8.jpg

    After that I tried putting this other image in..... saddly it covered the background and the character so the error didn't show its self up....

    http://i300.photobucket.com/albums/nn10/Callammutton/Error2.jpg

    And heres the code don't get me wrong I did try fixing this but after a few mins I knew I needed help.

    http://i300.photobucket.com/albums/nn10/Callammutton/Code.jpg


    If anyone could help mez on this it would be really greatful and thanks :3

    <Naut> Your images are huge. Read the rules.
    http://www.shrinemaiden.org/forum/index.php/topic,17.0.html
    « Last Edit: March 28, 2011, 05:13:22 PM by Naut »