A replacement for Danmakufu?

[Nuclear Cheese]

Bumping with a bit of update (I feel justified - we're on the second page :V)

Not much code work in the last few days.  I did add in a quick optimization to the collision routines that Theme suggested, but that's really it.

Dunno where Theme is; haven't heard from him all week (probably back to being busy.  stupid real-life commitments).


I have, however, been biting into the huge mess of work that is getting fonts to work.  It's coming along pretty well, but I'm still trying to figure out all of the details of it.

For the curious, I'm using the Tao mapping of FreeType to get each character as a bitmap, and then throwing that bitmap onto the screen.


I think it might be time for another testing release.  We've got a ton of new stuff since the last one, including:

• Object parameters
• Border image
• Arrays
• Object listing
• else
• Configurable keyboard input
• Fixed drawing order issue
• Sound effects and music

[Theme97]

Dunno where Theme is; haven't heard from him all week (probably back to being busy.  stupid real-life commitments).

Indeed. There's also some big stuff planned for Touhou Fortress planned for later and members have been dying off, so I've taken over some of the work. Combined with school (finals in two weeks ) and other such real-life commitments, MsD has been bumped down the list.

For collision stuff, I'll just leave that to you since I don't have any experience with it, but I'll keep an eye out for optimizations since netbooks aren't very good at running things quickly.

Once the font stuff is done I think I can get started on quite a few things (esp. the pause screen). I've also considered adding TATE but I'll wait for the semester to finish before seeing if I'll go through with that.

Tonight I'm going to look through mdScript stuff and commit the for() loop, *= and /= operators, and compound assignments on object parameters once I've got those tested. That's probably the last you'll see of me for the next couple of weeks.

Edit: Also, I had to get some SDL-related .dll files before I could get MsD to run without erroring out (at least SDL_image.dll and SDL_mixer.dll). Might want to figure out a way to make sure users get these in your next release because it was rather difficult to figure out that these were needed. (Or perhaps my SDL download didn't like me.)

[Nuclear Cheese]

Once the font stuff is done I think I can get started on quite a few things (esp. the pause screen). I've also considered adding TATE but I'll wait for the semester to finish before seeing if I'll go through with that.

Huh ... TATE mode could be cool.  In theory, it shouldn't be that hard to implement, either.

For fullscreen TATE, just apply a rotation to the entire play area and resize it to fit most/all of the screen, and remove/rework the border display.  Other than that it's just an issue of deciding how the HUD will be laid out in TATE mode.
Also, for everyone's sake - make sure it can rotate both ways!

Only major concern with throwing in TATE mode is that you need to make sure it doesn't break stuff.

Tonight I'm going to look through mdScript stuff and commit the for() loop, *= and /= operators, and compound assignments on object parameters once I've got those tested. That's probably the last you'll see of me for the next couple of weeks.

I just pulled down and checked through your changes.  It all looks fine to me.

Only detail I'd note is that, in C's for, you can leave the first (and third, if I remember correctly) field blank, so it'd look like this:

for (; foo > bar; bar++)

But, that's just minor details.

Edit: Also, I had to get some SDL-related .dll files before I could get MsD to run without erroring out (at least SDL_image.dll and SDL_mixer.dll). Might want to figure out a way to make sure users get these in your next release because it was rather difficult to figure out that these were needed. (Or perhaps my SDL download didn't like me.)

I just pulled the program up in Process Explorer to see what .dll's it's using.  Here's a list of the relevant ones I'm seeing:
Antlr3.Runtime.dll (included in previous testing release package; ANTLR runtime library)
Sdl.dll (not included in previous; SDL basic .dll)
SDL_image.dll (not included in previous; SDL image .dll)
SDL_mixer.dll (not included in previous; SDL audio handler .dll)
SdlDotNet.dll (not included in previous; SDL.NET basic .dll)
Tao.OpenGL.dll (included in previous; Tao Framework OpenGL interface .dll)
Tao.Sdl.dll (included in previous; Tao Framework SDL basic interface .dll)


It is probably a good idea to just include all of these, for the convenience of end users.  I should make a note to do so for the next testing release.
I'm so gonna forget. >__>



Reminder, back to the usual schedule of I'm-busy-with-family-stuff-on-weekdays-so-updates-only-on-weekends for me, at least for the next week or two (who knows what'll happen when the holidays come :V).

[Theme97]

Only major concern with throwing in TATE mode is that you need to make sure it doesn't break stuff.

Yeah, I'm concerned about TATE interfering with non-gameplay screens. Menus and such might have to be redesigned for a vertical screen and it might get messy.

Only detail I'd note is that, in C's for, you can leave the first (and third, if I remember correctly) field blank

Actually, you can leave all three fields blank and it'll become an infinite loop until you use a break to get out of it.

But then it just gets tricky and we kind of need to implement break first.

Speaking of that, there's also continue.


Edit: Wow, just realized this thread was started 3 months ago and I haven't read anything past page 1.

Anyway, got some TATE and SetImageRect() started but many of the issues are blocked on #11 so there's not much for me to do here.

I'm also not doing a good job of "being busy".

[Dizzy H. "Muffin" Muffin]

Couple random ideas I had:
- text-parsing functions, like substring(string, position of first character, length), explode(string-to-be-turned-into-array,delimiter) ... My motive for this was an idea whereby a script-maker could set things up so that you could give each player their own "script" file for e.g. pre-boss dialogue, so you wouldn't have to rewrite the code every time you had to wanted to add a new character/you could add non-default dialogues (say, for instance, if you wanted to do the equivalent of playing Sakuya in UFO). But you'd need string-parsing functions to do that ...
- giving the script read-access to the preferences, so you could e.g. tweak your script's graphics according to the resolution or something, or set up a custom framerate-counter. (Or pull a Psycho Mantis. "YOU'RE PLAYING THE GAME FULLSCREEN AT 1024x768 WITH SOUND DISABLED!")

[Nuclear Cheese]

Couple random ideas I had:
- text-parsing functions, like substring(string, position of first character, length), explode(string-to-be-turned-into-array,delimiter) ... My motive for this was an idea whereby a script-maker could set things up so that you could give each player their own "script" file for e.g. pre-boss dialogue, so you wouldn't have to rewrite the code every time you had to wanted to add a new character/you could add non-default dialogues (say, for instance, if you wanted to do the equivalent of playing Sakuya in UFO). But you'd need string-parsing functions to do that ...

The substring function is something I have plans to implement.  The explode function sounds like a useful thing as well.

- giving the script read-access to the preferences, so you could e.g. tweak your script's graphics according to the resolution or something, or set up a custom framerate-counter. (Or pull a Psycho Mantis. "YOU'RE PLAYING THE GAME FULLSCREEN AT 1024x768 WITH SOUND DISABLED!")

Sounds also useful, albeit a lower-priority feature.




Also, I unfortunately haven't been able to get anything done - been busy with kicking asses in fighting game casuals all weekend, and the remaining time is probably not going to yield anything significant.  Hopefully next weekend will be more productive.

[Nuclear Cheese]

Holy shit I actually got some work done here

• Fixed an issue where using the angle property always used radians, regardless of what the script specifies.
• Added PT8Sceptile's FireShot01S function, which fires bullets that don't rotate
• Added atan2 as an alias for arctan2
• Fixed an issue in the config file reader where it assigned the input for skip to focus instead.

And with that, it's Test Release 3!

I now included all of the SDL and Tao .dlls that it is using (as far as I could tell, anyways), so that'll lessen the need for searching those out.

Major new features include:

• Sound effects and music
• for loops and else
• Object listing
• Config file, allowing configurable input and video options

Per usual, if the program errors it'll close on its own.  Run it using the -l argument to get a log, and post information here.

[Theme97]

I now included all of the SDL and Tao .dlls that it is using (as far as I could tell, anyways), so that'll lessen the need for searching those out.

Code: [Select]

2009 Dec 19 16:06:10.125 - Error during initialization: The type initializer for 'SdlDotNet.Graphics.Surface' threw an exception.
Stack trace:
   at SdlDotNet.Graphics.Surface..ctor(IntPtr handle, Boolean isVideoMode)
   at SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface, Boolean frame)
   at SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface)
   at Musuu_no_Danmaku.Graphics.Initialize()
   at Musuu_no_Danmaku.Program.Main(String[] args)
Adding libpng12-0.dll solves this, and then it asks for zlib1.dll. After adding those two, it runs fine for me.

Finals are over so I can start getting things done again.

[Prime 2.0]

Code: [Select]

Musuu no Danmaku version 0.1.3640.32756
Starting logging file ...
2009 Dec 19 21:26:40.209 - Reading config file ...
2009 Dec 19 21:26:40.224 - Finished reading config file.
2009 Dec 19 21:26:40.224 - Initializing engine ...
2009 Dec 19 21:26:40.240 - Initializing graphics: 800x600 windowed, hardware surfaces enabled
2009 Dec 19 21:26:40.256 - Error during initialization: The type initializer for 'SdlDotNet.Graphics.Video' threw an exception.
Stack trace:
   at SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface)
   at Musuu_no_Danmaku.Graphics.Initialize()
   at Musuu_no_Danmaku.Program.Main(String[] args)

The program will close now.

I can't say I'm surprised. I even added those two DLLs Theme97 mentioned, didn't make a difference. Anyone else here with 64-bit XP having the same problem? I'm pretty sick of this not working. -_-

[Theme97]

EDIT: Hold up, SetVideoMode()? Looking into this again.


Hmm.

SdlDotNet.Graphics.Video contains

Code: [Select]

        static bool isInitialized = Initialize();

...

        /// <summary>
        /// Initializes Video subsystem.
        /// </summary>
        public static bool Initialize()
        {
            if ((Sdl.SDL_WasInit(Sdl.SDL_INIT_VIDEO))
                == (int)SdlFlag.FalseValue)
            {
                if (Sdl.SDL_Init(Sdl.SDL_INIT_VIDEO) != (int)SdlFlag.Success)
                {
                    throw SdlException.Generate();
                }
                return false;
            }
            else
            {
                return true;
            }
        }
The two Init functions in the Tao framework are just interfaces to SDL.dll, which has:

Code: [Select]

int SDL_Init(Uint32 flags) {
    #if !SDL_THREADS_DISABLED && SDL_THREAD_PTH
    if (!pth_init()) return -1;
    #endif

    SDL_ClearError();

    #if defined(__WIN32__)
    if (SDL_HelperWindowCreate() < 0) return -1;
    #endif

    if (SDL_InitSubSystem(flags) < 0) return (-1);

    if (!(flags & SDL_INIT_NOPARACHUTE)) SDL_InstallParachute();
    return (0);
}
SDL_InitSubSystem calls SDL_VideoInit here, which then does a whole mess of stuff that leads me to believe that I have no idea what is going on.

I'm on 32-bit XP, though, so that might be why it's working for me.

[Nuclear Cheese]

Code: [Select]

2009 Dec 19 16:06:10.125 - Error during initialization: The type initializer for 'SdlDotNet.Graphics.Surface' threw an exception.
Stack trace:
   at SdlDotNet.Graphics.Surface..ctor(IntPtr handle, Boolean isVideoMode)
   at SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface, Boolean frame)
   at SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface)
   at Musuu_no_Danmaku.Graphics.Initialize()
   at Musuu_no_Danmaku.Program.Main(String[] args)
Adding libpng12-0.dll solves this, and then it asks for zlib1.dll. After adding those two, it runs fine for me.

Finals are over so I can start getting things done again.

... okay, so I missed a few.  In my defense, neither have 'SDL' or 'Tao' in their name. :V

Code: [Select]

Musuu no Danmaku version 0.1.3640.32756
Starting logging file ...
2009 Dec 19 21:26:40.209 - Reading config file ...
2009 Dec 19 21:26:40.224 - Finished reading config file.
2009 Dec 19 21:26:40.224 - Initializing engine ...
2009 Dec 19 21:26:40.240 - Initializing graphics: 800x600 windowed, hardware surfaces enabled
2009 Dec 19 21:26:40.256 - Error during initialization: The type initializer for 'SdlDotNet.Graphics.Video' threw an exception.
Stack trace:
   at SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface)
   at Musuu_no_Danmaku.Graphics.Initialize()
   at Musuu_no_Danmaku.Program.Main(String[] args)

The program will close now.

I can't say I'm surprised. I even added those two DLLs Theme97 mentioned, didn't make a difference. Anyone else here with 64-bit XP having the same problem? I'm pretty sick of this not working. -_-

Can you do me a favor?

Download this, and repace the executable and try running it with -l.

It should still fail, but I added in a bit more output in regards to the error logging.  Specifically, I just found out that a thrown exception can have this InnerException property which could have more info.  It's a bit of a shot in the dark, but it might give us the solution.


Also, I appreciate that you haven't given up on getting this to work!

Hmm.

SdlDotNet.Graphics.Video contains

Code: [Select]

        static bool isInitialized = Initialize();

...

        /// <summary>
        /// Initializes Video subsystem.
        /// </summary>
        public static bool Initialize()
        {
            if ((Sdl.SDL_WasInit(Sdl.SDL_INIT_VIDEO))
                == (int)SdlFlag.FalseValue)
            {
                if (Sdl.SDL_Init(Sdl.SDL_INIT_VIDEO) != (int)SdlFlag.Success)
                {
                    throw SdlException.Generate();
                }
                return false;
            }
            else
            {
                return true;
            }
        }
The two Init functions in the Tao framework are just interfaces to SDL.dll, which has:

Code: [Select]

int SDL_Init(Uint32 flags) {
    #if !SDL_THREADS_DISABLED && SDL_THREAD_PTH
    if (!pth_init()) return -1;
    #endif

    SDL_ClearError();

    #if defined(__WIN32__)
    if (SDL_HelperWindowCreate() < 0) return -1;
    #endif

    if (SDL_InitSubSystem(flags) < 0) return (-1);

    if (!(flags & SDL_INIT_NOPARACHUTE)) SDL_InstallParachute();
    return (0);
}
SDL_InitSubSystem calls SDL_VideoInit here, which then does a whole mess of stuff that leads me to believe that I have no idea what is going on.

I'm on 32-bit XP, though, so that might be why it's working for me.

Hi Theme, you're posting while I'm posting. :V

[Theme97]

Hi Theme, you're posting while I'm posting. :V

Sup :V

Leaving this to you again since I can't be bothered to look for SDL_SetVideoMode in the Tao framework. Have fun.

[Prime 2.0]

Tried that test EXE out, error log coughed this stuff up:

Code: [Select]

Musuu no Danmaku version 0.1.3640.42532
Starting logging file ...
2009 Dec 20 00:16:26.021 - Reading config file ...
2009 Dec 20 00:16:26.021 - Finished reading config file.
2009 Dec 20 00:16:26.021 - Initializing engine ...
2009 Dec 20 00:16:26.037 - Initializing graphics: 800x600 windowed, hardware surfaces enabled
2009 Dec 20 00:16:26.052 - Error during initialization: The type initializer for 'SdlDotNet.Graphics.Video' threw an exception.
Stack trace:
   at SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface)
   at Musuu_no_Danmaku.Graphics.Initialize()
   at Musuu_no_Danmaku.Program.Main(String[] args)

The program will close now.
2009 Dec 20 00:16:26.084 - Inner exception: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
Stack trace:
   at Tao.Sdl.Sdl.SDL_WasInit(Int32 flags)
   at SdlDotNet.Graphics.Video.Initialize()
   at SdlDotNet.Graphics.Video..cctor()

The program will close now.

 :V

[Nuclear Cheese]

Tried that test EXE out, error log coughed this stuff up:

Code: [Select]

Musuu no Danmaku version 0.1.3640.42532
Starting logging file ...
2009 Dec 20 00:16:26.021 - Reading config file ...
2009 Dec 20 00:16:26.021 - Finished reading config file.
2009 Dec 20 00:16:26.021 - Initializing engine ...
2009 Dec 20 00:16:26.037 - Initializing graphics: 800x600 windowed, hardware surfaces enabled
2009 Dec 20 00:16:26.052 - Error during initialization: The type initializer for 'SdlDotNet.Graphics.Video' threw an exception.
Stack trace:
   at SdlDotNet.Graphics.Video.SetVideoMode(Int32 width, Int32 height, Int32 bitsPerPixel, Boolean resizable, Boolean openGL, Boolean fullScreen, Boolean hardwareSurface)
   at Musuu_no_Danmaku.Graphics.Initialize()
   at Musuu_no_Danmaku.Program.Main(String[] args)

The program will close now.
2009 Dec 20 00:16:26.084 - Inner exception: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
Stack trace:
   at Tao.Sdl.Sdl.SDL_WasInit(Int32 flags)
   at SdlDotNet.Graphics.Video.Initialize()
   at SdlDotNet.Graphics.Video..cctor()

The program will close now.

 :V

Huh, now this brings up some interesting points.

From some quick google diving, it seems this means it's attempting to mix 32-bit and 64-bit executables/dlls.  Here's one of the sources I found stating this - it's a different line, but it sounds like the same basic problem.

It seems what's likely happening is that your 64bit system is JIT-ing the CLI code to native 64bit, but then it's trying to associate with 32bit dlls (the ones included with the program are 32bit, fyi).


From a quick bit of research, there's a couple possible solutions:


1) find 64bit versions of the SDL dlls.
If you can get the appropriate 64bit dlls, then the 64bit JIT'd code will match up and it should run fine.  I know there were a couple other people who got this running under 64bit Windows, so maybe they can help?


2) adjust compiler options to force 32bit mode
Probably the easier solution in the short term, but it might cause some issues.  It would allow it to use the 32bit dlls, since it'll be running in 32bit mode.  But, at the same time it means it'll be running in a suboptimal processing mode, and there might be some unknown side-effects (although I would hope not).

Plus, it adds to the logistics of distribution a bit, since now we'd have two executables (the standard "do whatever" one, and the "force 32bit" one).


I really need to start thinking about sleep* now, but I'm most likely going to have a bunch of time to look at it this coming week, so hopefully we can get a test fix in order soon!

* More fighting game casuals yesterday.  I didn't get home until 7am!





EDIT:


Prime2.0, try this executable out, if you can please - www.stephenware.com/musuu_no_danmaku/2009_Dec_19_test_exe_x86.zip

I just recompiled the program with target CPU as x86, which should force it into 32bit mode.  Based on my previous interpretation of the error message, I think it stands a good chance of working.


Once again, I appreciate your patience and persistence with this!
/canned_corporate-style_response

[Prime 2.0]

It worked!

It was also absolutely nothing like I expected it to be. Test release 3 was supposed to have sound, right?

Anyways, this just occurred to me, but is the Musuu no Danmaku name set in stone? It occurred to me recently that you could maybe name it Bullet Forge, to coincide with that danmaku scripting website that Blargle was making. Well, that and it just sounds a lot cooler. I guess you'd have to ask him first. I feel awkward for even bringing this up. ._.

[Nuclear Cheese]

It worked!

It was also absolutely nothing like I expected it to be. Test release 3 was supposed to have sound, right?

Anyways, this just occurred to me, but is the Musuu no Danmaku name set in stone? It occurred to me recently that you could maybe name it Bullet Forge, to coincide with that danmaku scripting website that Blargle was making. Well, that and it just sounds a lot cooler. I guess you'd have to ask him first. I feel awkward for even bringing this up. ._.

Extacy and celebrations! :toot:

Test release 3 has support for sound and music, but the included scripts don't actually use it, since I don't have any sound/music files I can distribute with the game.
For testing, I use an sfx I grabbed from a Danmakufu script and a track from the Guilty Gear Isuka soundtrack (Fille de Vent, to be precise ^_^ ).

In you look in TheEnemy.txt, you'll find that the music and sound effet commands are there, but commented out.  If you add in the appropriate files and uncomment the lines, you should have audio; if not, then it's probably a bug.



As far as the name, there was a bit of discussion a while back, and we ended up sticking with Musuu no Danmaku.  There's still room for suggestions, if you have a good one, but I think at this point the name is set pretty well in place.

And as far as using the same name as Blargel's website, I think that wouldn't make too much sense, since the website will deal with other engines, as well.

[PT8Sceptile]

The x86 version worked fine on my Windows Vista that couldn't run the last 2 releases, so I can assume you found the correct cause for the problem. Excellent work!

[Nuclear Cheese]

The x86 version worked fine on my Windows Vista that couldn't run the last 2 releases, so I can assume you found the correct cause for the problem. Excellent work!

Glad to hear you've got it working too!


To sum it up, it was trying to mix together 32bit and 64bit code (you are running Vista64, I assume), which doesn't work.

[Stuffman]

Just reporting in to say I finally got around to trying the demo, and everything is working very smoothly.

[Nuclear Cheese]

Just reporting in to say I finally got around to trying the demo, and everything is working very smoothly.

Glad to hear it!



Just poking in to give you guys a bit of an update - font rendering is in!

Took me a bitchandahalf of effort to get FreeType to play along (mostly because I'm an idiot, but what else is new? :V), but you can now draw text from your scripts, using the Mona font.  Syntax is as follows:

DrawText(text, x, y, color, size, layer);

• text can be a string, a number, or a boolean - the program will render them all.  No support for rendering arrays, at least currently.
• x and y determine the position.  It should be noted that FreeType bases the position off of the lower-left, so for the time being that is what this refers to as well.
• color is a three-element array giving the R, G, and B of the color.  I will be adding in some constants for typical colors.
• size is the size of the text to be rendered
• layer is the graphics layer on which to render the text (things on a higher layer will render above it, per usual).

Currently, this is called in your tick script, since we don't yet have a dedicated draw script ... perhaps that should be added in soon? (Although, to note, you'll always be able to use it from wherever, if for some reason you want to do that ...)



It's looking good performance-wise, but I will warn that it is definitely a bigger performance hit than other rendering (Danmakufu has this too - the help warns that the DrawText function is pretty "heavy").


I still need to give it some thorough testing before I commit it to the source repository, but it's there.


PS - sorry for the slow progress recently, but you know, holidays and such.
(and birthday this coming Tuesday :3)

[Azure Lazuline]

I have three suggestions for this - would it be possible to allow a gradient for the color, like DMF? Also, there seems to be lacking an opacity option, which might be problematic in some cases. Third, to cut down on render time, perhaps there could be an option to pre-load the text and convert it into a graphic? This shouldn't be a priority of course, but it would be nice to have.

[Naut]

I dunno if this was asked and/or addressed yet, but will there be 3D? Perhaps I'm getting ahead of the project a little.

[Nuclear Cheese]

I have three suggestions for this - would it be possible to allow a gradient for the color, like DMF?

I had thought about this; wasn't sure if people wanted it.  Should be pretty easy to add in.

Also, there seems to be lacking an opacity option, which might be problematic in some cases.

I can add in an alpha value as well, although with the current setup it'll make the rendering a bit slower.

Third, to cut down on render time, perhaps there could be an option to pre-load the text and convert it into a graphic? This shouldn't be a priority of course, but it would be nice to have.

This is a possibility - if your script knows in advance it needs "MY AWESOME SCRIPT" in 60-point bright-red lettering every frame, it could buffer that into a texture and render it more like a normal image.

I dunno if this was asked and/or addressed yet, but will there be 3D? Perhaps I'm getting ahead of the project a little.

This has been brought up once or twice.  There will be 3D graphics commands, but they are low-priority at the moment, so they're probably not going to be added in very soon.

[Stuffman]

This is a possibility - if your script knows in advance it needs "MY AWESOME SCRIPT" in 60-point bright-red lettering every frame, it could buffer that into a texture and render it more like a normal image.

Actually this reminds me of a feature in some other engines, where you could create a new image (like, image=CreateImage(64,64); and it would give you a transparent image 64x64) and have the ability to draw on that instead of the screen (DrawGraphicOnImage or something); then you could draw that image to the screen after you've modified it. You could also copy an area of the screen and put that in an image.

[DarkslimeZ]

Actually this reminds me of a feature in some other engines, where you could create a new image (like, image=CreateImage(64,64); and it would give you a transparent image 64x64) and have the ability to draw on that instead of the screen (DrawGraphicOnImage or something); then you could draw that image to the screen after you've modified it. You could also copy an area of the screen and put that in an image.

But then again, this is more memory intensive. It's a tradeoff.

Though, with RAM sizes these days... ^^;

[Azure Lazuline]

Yeah, a "copy this section of the screen to an image" function would be fun too, just so you could add PoFV-like screen transitions. (Hey, you can't have a shooter game without at least one pointlessly cool transition effect...)

[Blargel]

Dunno if this has been mentioned already 'cause I'm not gonna read 16 pages of stuff, but Danmakufu has really messed up 3D rotation when you try to rotate on multiple axes at once. I believe this is due to the use of matrix transformations. A better way to handle rotation would be to use quaternions instead. I dunno how either work, but just throwing it out there

[Nuclear Cheese]

Actually this reminds me of a feature in some other engines, where you could create a new image (like, image=CreateImage(64,64); and it would give you a transparent image 64x64) and have the ability to draw on that instead of the screen (DrawGraphicOnImage or something); then you could draw that image to the screen after you've modified it. You could also copy an area of the screen and put that in an image.

This could certainly be possible, at least once I figure out where OpenGL's render-to-texture functionality is kept.

But then again, this is more memory intensive. It's a tradeoff.

Though, with RAM sizes these days... ^^;

Take, for instance, Stuffman's 64x64 texture ...

64 * 64 = 4096 pixels
* 4bytes/pixel = 16384 bytes = 16kB

Not really that much by today's standards.  Plus, assuming everything's working as it should that'll get shoved right off to the graphics card's RAM, so it won't even be bogging down the system's memory usage.

Yeah, a "copy this section of the screen to an image" function would be fun too, just so you could add PoFV-like screen transitions. (Hey, you can't have a shooter game without at least one pointlessly cool transition effect...)

This would be a bit trickier.  In order to get all of the layers rendered in the proper order, Musuu no Danmaku does not render any images until after all script processing has completed.  Therefore, if you request a snapshot of the screen, it won't be available until the next frame.

Plus, grabbing such an image won't be "cheap", so I don't think we could cache it every frame in case a script might request it later.

Dunno if this has been mentioned already 'cause I'm not gonna read 16 pages of stuff, but Danmakufu has really messed up 3D rotation when you try to rotate on multiple axes at once. I believe this is due to the use of matrix transformations. A better way to handle rotation would be to use quaternions instead. I dunno how either work, but just throwing it out there

1) "I dunno how X works, but I suggest using X." :V
Sorry, I just find this boiled-down version of your statement amusing.

2) Danmakufu's rotation is based on three individual rotations, one about each of the primary axes, applied in sequence.  The only thing I found really strange about it was the order in which they seemed to be applied.

3) Everything in 3D graphics boils down to matrix math.  Even if you give it a quarternion for a rotation, internally it converts it to the appropriate matrix.

4) Quarternions are no joke mathematically - no joke.


... with all that said, I do agree that we need a better 3D rotation function than Danmakufu provides.

OpenGL has a function to specify a rotation of t degrees about vector (x, y, z).  Might be a good starting point, but we might have to "stack" rotations in order to get all possible results, and this gets confusing pretty quickly.

[anonl]

This could certainly be possible, at least once I figure out where OpenGL's render-to-texture functionality is kept.

http://en.wikipedia.org/wiki/Framebuffer_Object
FBO's aren't supported on older Intel GPU's though...

[Theme97]

Danmakufu's rotation is based on three individual rotations, one about each of the primary axes, applied in sequence.

Argh, gimbal lock sucks but Euler angles are the easiest to understand.

OpenGL has a function to specify a rotation of t degrees about vector (x, y, z).  Might be a good starting point, but we might have to "stack" rotations in order to get all possible results, and this gets confusing pretty quickly.

Huh, really? I made a plugin for Team Fortress 2 a while back where rockets would gradually turn to home in on a player. It worked by creating a vector from the rocket's position to the player and then getting the up vector. Each frame, it would rotate the rocket's velocity vector around that up vector, and the plugin never had problems with that.