Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Fat Cerberus
2836
It's a G3 Core i7, so Intel HD Graphics 4000 I believe. I've played Team Fortress 2 and Portal 2 on this machine at 1080p and it doesn't lag at all, so quite jarring for a 2D engine like TurboSphere to fail entirely.
2837
Tried to run it, got this output (had to run it from PowerShell just to get the output as the console window closed immediately when run from Explorer):
Code: [Select]
Fixed plugins: 1
Fixed plugins as recorded: 1
Opening Game.
Opening SGM file startup/game.sgm
Opening main script.
The main script is startup/scripts/Jest_Main.js
Opening script startup/scripts/Jest_Main.js
Getting number of plugins.
Getting number of plugins.
Plugin graphicSDL_GL.dll is open.
[SDL_GL] Video mode setup succeeded.
[SDL_GL] Error: GL_EXT_pixel_buffer_object is not present.
2838
I am thinking that it might be useful to have an image.tileBlit function, that blits an image with a given x, y, (and maybe width and height), and repeats it a given number of times for the width and height (or just makes the dimensions the base dimensions * number of repeats). Mostly because I found that quite a useful thing to do with a modified Majestic, and it can be done very easily in hardware.
Bending the texturing hardware to your will, huh?
2840
Getting back on topic: Much of the Specs battle engine is programmed. I had been putting this off for a long time due to the sheer complexity of the design, but thanks to a drop-dead simple Console class I programmed in an hour last night, I've been making a lot of progress. I suppose not having to waste time finding (or making) placeholder sprites to see what's going on in the battle helps. 
Stuff that's implemented:
-- Turn resolver (resolves turn order based on battler stats/move used)
-- Action queue - for multi-turn moves
-- Enemy AI framework
-- Status effect framework (WIP)
-- Weapon switching framework (WIP)
Quite an impressive list I think, considering the battle engine didn't do a thing a few days ago--although to be fair several pieces of the framework were already in place as of my initial git commit, albeit not operational.
Anyway, that's my status update for today. I'm getting closer to releasing the Tech Demo, but that will require an actual battle screen layout first, so it's still a ways off. Sit tight, I promise it'll be worth the wait!
Stuff that's implemented:
-- Turn resolver (resolves turn order based on battler stats/move used)
-- Action queue - for multi-turn moves
-- Enemy AI framework
-- Status effect framework (WIP)
-- Weapon switching framework (WIP)
Quite an impressive list I think, considering the battle engine didn't do a thing a few days ago--although to be fair several pieces of the framework were already in place as of my initial git commit, albeit not operational.
Anyway, that's my status update for today. I'm getting closer to releasing the Tech Demo, but that will require an actual battle screen layout first, so it's still a ways off. Sit tight, I promise it'll be worth the wait!
2841
Haha, forgot you have to manually create a delegate with a hook list, I think I got spoiled with C# since there you can just specify obj.method and it does the right thing automatically.
Is method.bind() native JS functionality though? I thought you needed an extra script for that... If not then I'm a complete idiot for rolling my own delegate() function...
Is method.bind() native JS functionality though? I thought you needed an extra script for that... If not then I'm a complete idiot for rolling my own delegate() function...
2842
The sound I could do without; it's still pretty early in Specs' development process. But yeah, the lack of a map engine is kind of a dealbreaker. Oh well, no need to rush, better to take your time and do it right than push out buggy code as a release. I should know, having had plenty of experience with that--I've been working on the Spectacles Saga since 2006 at least! ;-) Well, not the programming, but other aspects of it (story, characters, etc.)
As for OpenGL: Isn't it nice that pretty much every processor has a GPU built in now? It's finally viable to make a 2D game that relies on hardware graphics acceleration without having to worry if it'll run on a low-end machine. Even the cheap AMD APUs like the crappy E2 processor in my all-in-one desktop are worlds better than the onboard graphics of a few years ago. I can actually run 3D games at decent settings on it!
As for OpenGL: Isn't it nice that pretty much every processor has a GPU built in now? It's finally viable to make a 2D game that relies on hardware graphics acceleration without having to worry if it'll run on a low-end machine. Even the cheap AMD APUs like the crappy E2 processor in my all-in-one desktop are worlds better than the onboard graphics of a few years ago. I can actually run 3D games at decent settings on it!
2843
Once I unify my older surface code with the new OpenGL system and I get the other plugins working with OpenGL, I'll make a release. A big, beautiful, high-performance, amazing release.
You mean one that I can port Spectacles over to? :-) That'll be nice, finally being able to get off of the five-year-old 1.5 engine!
2844
One thing about the way you are copying over plugins: Good idea, but that relies on plugins having to end with the word 'Plugin'. For now I'm doing this, and I guess for the initial plugins that come with the editor this is fine. Plugin's don't have to end with the word 'Plugin', but that's just a minor point.
Yeah, I figured that. I suppose you can always edit the build settings later if needed (Project properties -> Build Events). Right now all the default plugins DO end in "Plugin" so it was the simplest way to get it to move all the DLLs at once. The main point behind it was so you always have the latest build of all your plugins for debugging, and you also get the correct build for x86/x64 and release/debug without having do a manual file-copy dance all the time. When using Visual Studio, I tend to prefer having the IDE do as much manual labor for me as possible.
Edit: Bug I found: The Save button on the toolbar is permanently grayed out ever since you implemented the script plugin. Not a big deal as File->Save and Ctrl+S still work, but might confuse new users. Oh, and I discovered an old Thumbs.db in the repo (only found it because Windows had changed my copy and git wanted to commit it even though it was in .gitignore, stupid git bug), but it'd be ridiculous to create a pull request just for something so trivial, so I guess you can delete it yourself if you feel like it.
Oh, one more thing: I tried to move the audio player to a plugin myself using the script editor as a basis, but got confused as hell by the plugin API. I couldn't figure out what was part of the plugin architecture and what was part of the script editor itself. Any chance you could mock up some documentation for the plugin API?
2845
The current version is kh2Bar 2.0 released July 10, 2013. A demo project and screenshot are attached.
Changelog:
v2.0
v1.6.1:
v1.6:
v1.5.1:
v1.5:
v1.0:
Usage:
For each kh2Bar you have on-screen, you'll have to call its .update() and .draw() methods once per frame.
Whenever the amount of HP changes and you want the lifebar to reflect it:
If you need to hide the gauge temporarily (for a cutscene, etc.) just call hide(), and later show() when you need it to be visible again. Both take an optional parameter specifying the amount of time over which to fade it in/out.
Changelog:
v2.0
- New maxSectors argument for kh2Bar() constructor, useful if you need to guarantee a gauge can fit a certain number of reserve sectors.
- New combo functionality: Call .beginCombo() to start a combo. Any damage sustained during the combo won't fade away until .endCombo() is called.
- New .changeColor method to adjust the color of the gauge after creation.
- Fixed long-standing glitchiness when recovering HP.
- Gauge now drains smoothly when reading is changed.
- Added checks for correct number of arguments to user-facing methods.
v1.6.1:
- Updated fill logic so bar is never empty if HP is nonzero
v1.6:
- Lots of refactoring.
- Renamed render() to draw().
- New show/hide functionality with optional fade in/out. Gauge is hidden upon creation.
v1.5.1:
- Fixed a few off-by-one errors in kh2Bar.render() that were causing the gauge to be filled inconsistently depending on the amount of damage displayed.
v1.5:
- Updated presentation: The new version is much more faithful to the KH2 design. The main lifebar is right-aligned, and if the bar on top is only a partial (as when the gauge is full and maxHP isn't an exact multiple of the sector size), the bar underneath shows through.
- Constructor no longer takes x and y parameters; these have been moved to kh2Bar.render().
- Changed 'reading' property to plain methods as getter/setter methods are SpiderMonkey-specific.
- The size of the gauge is no longer hard-coded: kh2Bar.render() now also takes 'width' and 'height' as parameters.
- Sector size (HP per bar) is now customizable via an optional constructor parameter. The default is 100.
- Color of the gauge is also customizable. The default color is green (#00FF00 @ 100% opacity), as in KH.
v1.0:
- First release.
Usage:
For each kh2Bar you have on-screen, you'll have to call its .update() and .draw() methods once per frame.
Code: (javascript) [Select]
RequireScript("kh2Bar.js");
// maxHP is required, sectorSize and color are optional. If not provided, the default values are
// sectorSize: 100 (100 HP per bar) and color: #00FF00 (green) @ 100%.
var lifebar = new kh2Bar(maxHP, sectorSize, color);
lifebar.show(); // bar is initially hidden, must call show() or the player won't see it
// Inside your game loop:
lifebar.update();
lifebar.draw(x, y, width, height);
Whenever the amount of HP changes and you want the lifebar to reflect it:
Code: (javascript) [Select]
lifebar.set(currentHP);
If you need to hide the gauge temporarily (for a cutscene, etc.) just call hide(), and later show() when you need it to be visible again. Both take an optional parameter specifying the amount of time over which to fade it in/out.
2846
I think I remember now. The reason I had Scenario hijack the map engine instead of using user-accessible update/render hooks was because I didn't want Scenario.run() to return until the scene was over. This makes it much easier to add teardown code (setting event flags, etc.) after the scene. I suppose I could refactor everything to make this requirement unnecessary, but that would be Scenario 4.0, which I don't expect to be able to do for a while, as I have a few other time-consuming changes planned for 4.0.
2847
I'm getting a NullReferenceException when enabling the task list plugin in the options, the Visual Studio debugger highlights the Plugin.Initialize call in PluginWrapper.cs at the time of the error, but checking the call stack and variables, everything looks okay so I'm not sure what's going on. Any chance you could check this out?
Edit: Nevermind, I figured it out. It was trying to read a property from CurrentGame, but if no project is loaded, CurrentGame is null. It's fixed now. I also fixed the references so the most recently-built copy of the plugins is used all the time, without having to manually add the DLLs to the VS project tree. Should make debugging plugins easier now, as well.
Edit 2: Really weird bug in the script editor, I don't even know where to begin looking for this one: With the new script plugin, Ctrl+V (or Edit->Paste) seems to paste the text into a new Untitled file instead of into the current script. Really strange behavior. The only way I was able to paste was to right-click the Scintilla control itself.
Edit: Nevermind, I figured it out. It was trying to read a property from CurrentGame, but if no project is loaded, CurrentGame is null. It's fixed now. I also fixed the references so the most recently-built copy of the plugins is used all the time, without having to manually add the DLLs to the VS project tree. Should make debugging plugins easier now, as well.
Edit 2: Really weird bug in the script editor, I don't even know where to begin looking for this one: With the new script plugin, Ctrl+V (or Edit->Paste) seems to paste the text into a new Untitled file instead of into the current script. Really strange behavior. The only way I was able to paste was to right-click the Scintilla control itself.
2848
The rationale was that it was supposed to be a cutscene manager, rather than a map engine wrapper, and I think that's what you really wanted with your Scenario - a map engine wrapper.
I'm not sure I follow you here. Scenario as written right now is basically useless outside of cutscenes, it hardly qualifies as a map engine wrapper. "Wrapper" to me implies a library whose sole reason for existing is to repackage existing functionality with a different interface--which isn't what Scenario is meant to be at all. It can be used that way, sure, but that isn't what it's designed for (I wouldn't have gone to all the trouble to implement fork & synchronize if that were the case!). The only reason Scenario takes over the map engine update/render calls is because... hm, now I don't remember why I did it that way, actually! My first instinct is it had something to with allowing it to just be dropped into any existing project and used right away regardless of that project's existing custom update/render scripts, but I feel like there must have been a more concrete reason than that...
2849
If I'm being honest, I originally designed Scenario under the assumption that the player will never have control of the map engine during a cutscene, but in practice I don't see why it shouldn't work. The only thing I can think of is some sort of weird race condition with map updates. I don't know exactly what you did when you incorporated Scenario into NShoot, but I do know the official version runs its own update loop, including calls to RenderMap() and UpdateMapEngine(). Depending on what your setup is, it's possible the map engine is getting updated twice in a frame, which would of course knock Scenario out of sync since scenelets still only get one update per frame.
2850
Huh? auto in C++ merely specifies a local variable, and is the default if not specified anyway. Unless they changed the meaning in C++11?