cinematX - 1.0 is on its' way

[Rednaxela]

That way it doesn't need to increment it twice. and still achieves the same effect.

Personally, I think "uid = npcCount + 1" followed by the increment is a little cleaner in some ways. What I mean is, in my mind at least, it's cleanest for counters of some event (such as IDs being assigned) to, as a rule, increment after the event rather than at any point prior to the event. Incrementing a counter just after is always possible for counters of an event, whereas incrementing prior is only possible in some cases, and always following the same convention when possible makes for more consistent code. I view the "uid =" line as the event being counted as that is the line that formally assigns the UID. In addition, "uid = npcCount + 1" also makes it very clear that the UIDs starting at 1 is intentional, whereas doing so by rearranging lines is a little less explicit that it was intentional unless you also add a comment to the code.

EDIT: I would however be cool with the rearranging of lines you propose, if one also took the additional step of renaming "npcCount" to something like "lastestUID", because that would make the line where you increment it the line that formally assigns the next UID, rather than a counter of the number of UIDs that have been assigned.

Still, CinematX will hopefully be re-worked at some point in the future to make use of eventu and pnpc. I'd do it myself, but I don't really have to time to re-implement everything properly.

Agreed. Last night had the thought that maybe I should give it a go some time, and the library ought to be quite a bit smaller when leveraging eventu and pnc. Lots of other things to be working on though, and a risk of accidentally creating subtle compatibility problems.

[Hoeloe]

Agreed. Last night had the thought that maybe I should give it a go some time, and the library ought to be quite a bit smaller when leveraging eventu and pnc. Lots of other things to be working on though, and a risk of accidentally creating subtle compatibility problems.

Yeah, the potential compatibility issues was why I haven't given it a go. In theory, it should just be a case of abstracting the old cinematX commands through the new implementation (this should be particularly easy for the eventu stuff, which was mainly based on cinematX to begin with), but in practice it will likely end up a little more complicated.

[Onule]

Hey, I've been trying an NPC that talks in section 20, has a helloVoice, idle animations and faces the player

Code: Select all

do
	function onLoop()
		toadActor = cinematX.getActorFromKey ("toad1")	
		if toadActor ~= nil then	
			toadActor:overrideAnimation (animData_Toad)
			toadActor.helloVoice = VOICEID_TOAD_04
			toadActor.shouldDespawn = false
			toadActor.shouldFacePlayer = true
	end	
end
end

This doesn't seem to work, but the NPC says there and is talkable.

Code: Select all

do
	function onLoopSection19()
		toadActor = cinematX.getActorFromKey ("toad1")	
		if toadActor ~= nil then	
			toadActor:overrideAnimation (animData_Toad)
			toadActor.helloVoice = VOICEID_TOAD_04
			toadActor.shouldDespawn = false
			toadActor.shouldFacePlayer = true
	end	
end
end

Works, but the NPC only appears once. Is there something I'm doing wrong?

[Rixithechao]

Arright, time to dust off this thread a bit.

First things first, were you ever able to resolve that issue, Onule? I recall there was some weirdness with section-specific loading and/or looping in earlier versions of LunaLua, but I also wouldn't be surprised if it was a bug with cinematX. If you're still stuck on that bug and updating to the latest versions of LunaLua and cinematX doesn't fix it, PM me so we can get it figured out.

Now, regarding cinematX's development, version 0.0.8 is in the works. It will not be restructured to use the eventu and pnpc libraries, but that is still planned for a future version.

The following features are either already implemented or are currently being worked on:

- Variable-length screen fade transitions
- Screen tinting
- Sleeker UI elements using the OpenGL renderer, with the original image-based UI still available for compatibility
- Player input will finally be disabled properly during cutscenes while still allowing for the Player character to be controlled as an Actor
- Wrapper functions for playSFX and playSFXSDL that prevent sounds from being played multiple frames in a row

Planned features for v0.0.9:
- UI configurable to use either sprite or OpenGL menus based on your computer's graphical capabilities
- Camera controls: zooming and panning


Last but not least, due to a quirk of the OpenGL renderer NPCs with sprite sheets larger than your GPU's texture limit will display as white boxes. As such, NPCs with extensive animation, such as the ones in the sample levels, will not display correctly on some computers (mine included ). There's not much I can do about this problem other than wait for the renderer to be patched.

[Hoeloe]

due to a quirk of the OpenGL renderer

Not really a quirk of OpenGL, more a quirk of rendering on the GPU, and the limit will depend on your hardware, so it's worth keeping in mind that sheets larger than 2048 pixels in any direction may not render properly on some GPUs. Some may not even manage that, but most will cope up to that point. Some support up to 4096, and most gaming cards will support 8192, but 2048 should cover most cases.

[Rixithechao]

due to a quirk of the OpenGL renderer

Not really a quirk of OpenGL, more a quirk of rendering on the GPU, and the limit will depend on your hardware, so it's worth keeping in mind that sheets larger than 2048 pixels in any direction may not render properly on some GPUs. Some may not even manage that, but most will cope up to that point. Some support up to 4096, and most gaming cards will support 8192, but 2048 should cover most cases.

The quirk I was referring to was the fact that the renderer lacks texture stitching to circumvent the GPU's limits, but I suppose "nuance" or something to that effect would've been a better way to phrase it. It wasn't my intent to harp on Rednaxela or the renderer anything, I was just trying to get a word of caution out about the new limits.

The only thing I can think of to possibly minimize the issue for the time being is optimizing the animation routine to use unidirectional sheets, and that's only if SMBX can render both directions from a single frame which, to my knowledge, isn't the case. I could still use npcconfig.lua to automate some of the animation setup once that library gets out of alpha, though.

...Now that I think about it, I should probably give the judges and/or raocow a heads-up about this stuff in case any of the cinematX levels show up in the LP soon.

[Hoeloe]

I could still use npcconfig.lua to automate some of the animation setup once that library gets out of alpha, though.

That library isn't going to get out of alpha unless some gets around to testing it. The only reason it's in alpha at the moment is because some of the effects of the values are unknown. I don't have time to test it myself, though, so it's just sitting in alpha.

Even so, that's not a great solution because those values affect all NPCs of that type, not just specific ones, so it will greatly restrict how NPCs can be used.

[Rixithechao]

I could still use npcconfig.lua to automate some of the animation setup once that library gets out of alpha, though.

That library isn't going to get out of alpha unless some gets around to testing it. The only reason it's in alpha at the moment is because some of the effects of the values are unknown. I don't have time to test it myself, though, so it's just sitting in alpha.

Even so, that's not a great solution because those values affect all NPCs of that type, not just specific ones, so it will greatly restrict how NPCs can be used.

The idea wouldn't be to change the values, just read them... but I suppose the only real benefit would be removing the need to give the frame count in the actor's Animation data.

[Hoeloe]

The idea wouldn't be to change the values, just read them... but I suppose the only real benefit would be removing the need to give the frame count in the actor's Animation data.

Which is a fairly big benefit to be honest.

The library is safe if all you want to do is read a couple of values.

[Rednaxela]

...Now that I think about it, I should probably give the judges and/or raocow a heads-up about this stuff in case any of the cinematX levels show up in the LP soon.

Horikawa is already aware of this (she was the first one to notice the issue actually, which led to us discussing it).
(Also, I'm thinking I may get the texture stitching worked out this weekend)

[Rednaxela]

due to a quirk of the OpenGL renderer

Not really a quirk of OpenGL, more a quirk of rendering on the GPU, and the limit will depend on your hardware, so it's worth keeping in mind that sheets larger than 2048 pixels in any direction may not render properly on some GPUs. Some may not even manage that, but most will cope up to that point. Some support up to 4096, and most gaming cards will support 8192, but 2048 should cover most cases.

The quirk I was referring to was the fact that the renderer lacks texture stitching to circumvent the GPU's limits, but I suppose "nuance" or something to that effect would've been a better way to phrase it. It wasn't my intent to harp on Rednaxela or the renderer anything, I was just trying to get a word of caution out about the new limits.

Psst, some basic texture stitching is now implemented. When a SMBX texture exceeds the limit for the GPU, it'll be split into multiple sub-sprites to be rendered as-needed. This shoooould make that those large cinematX sprites work for you again.

I've tested this by artificially setting a low maximum texture size, but don't have something on hand with an actually small texture limit. So, would you mind giving this build a shot Rocky?
LunaLUA_0.7.0.2plus1Red.zip

Note, this is only (currently) for SMBX sprites, not for Lua loadImage calls. I could make it work for loadImage calls, but it would only give a sensible result with placeSprite, not with glSetTexture, because it would get rather tricky to try to handle the split textures with the level of control the more direct gl calls have.

[Rixithechao]

Psst, some basic texture stitching is now implemented. When a SMBX texture exceeds the limit for the GPU, it'll be split into multiple sub-sprites to be rendered as-needed. This shoooould make that those large cinematX sprites work for you again.

I've tested this by artificially setting a low maximum texture size, but don't have something on hand with an actually small texture limit. So, would you mind giving this build a shot Rocky?
LunaLUA_0.7.0.2plus1Red.zip

Note, this is only (currently) for SMBX sprites, not for Lua loadImage calls. I could make it work for loadImage calls, but it would only give a sensible result with placeSprite, not with glSetTexture, because it would get rather tricky to try to handle the split textures with the level of control the more direct gl calls have.

It works perfectly! :D

[Hoeloe]

Note, this is only (currently) for SMBX sprites, not for Lua loadImage calls. I could make it work for loadImage calls, but it would only give a sensible result with placeSprite, not with glSetTexture, because it would get rather tricky to try to handle the split textures with the level of control the more direct gl calls have.

That sounds sensible to me. glSetTexture should be a pretty low-level version of the image drawing stuff, and can easily be managed manually as necessary. I think it's fine to leave texture stitching out of that.

[Rixithechao]

First cinematX level in MaGLX2!
...First realization that maybe not everyone was super-excited about the UI graphics I kinda forced into levels that use the library.

So an option to toggle off the HUD box will be in version 0.0.8, and here's a package of some of those UI graphics redone to use proper alpha transparency!
https://drive.google.com/file/d/0B-w323 ... sp=sharing

Simply replace the files in the LuaScriptsLib > cinematX folder with their png counterparts and update the filenames in cinematX.lua.

Other new additions to v0.0.8:
- the coroutine stuff now uses the eventu library
- cinematX.waitFrames (it's literally just calling eventu.waitFrames but yeah)
- cinematX.yield ()
- cinematX.lerpScreenTint (newCol, timeAmt) to smoothly transition between different screen tints

[Hoeloe]

Other new additions to v0.0.8:
- the coroutine stuff now uses the eventu library
- cinematX.waitFrames (it's literally just calling eventu.waitFrames but yeah)
- cinematX.yield ()
- cinematX.lerpScreenTint (newCol, timeAmt) to smoothly transition between different screen tints

Suggest adding some screen transition scripts. I've tried doing some fading, but it's fairly convoluted at the moment. Would probably need OpenGL though.

[Rixithechao]

Dagnabbit rocky you really need to stop being weirdly hesitant to publish posts until the absolute last minute

Suggest adding some screen transition scripts. I've tried doing some fading, but it's fairly convoluted at the moment. Would probably need OpenGL though.

Already implemented fading as mentioned in this post and seen in the

Ultimate Pandamona

battle (though to be fair, I only thought to add some stuff like the yield and screen tint lerp functions to cinematX after hard-coding them in that boss). Fading and tints both use OpenGL, and it automatically fades out when entering a door or pipe and fades in when entering a section (this can be toggled off via config).

I went ahead and made a roadmap back when I first started writing this reply... don't have super-solid plans beyond this next update, but I'll cross that bridge once I get to it.

[Rixithechao]

Okay, so... v0.0.8a has been committed to Github. It's currently broken due to an issue with comparing LuaImageResource variables, though that's been fixed in the lunalua source. So, in theory, once the update with that fix is out, 0.0.8a should work.

There may be a few compatibility issues, though I've tried to keep them minimal this time around. The new features can probably be optimized more -- the screen fade functions don't use the new fade library, for example -- and I've only really used them with the Broadsword and Pandamona battles, so they'll need further testing.

Since it's now a dependency, I've also included graphX.lua: a watered-down, incomplete version of the colliders library for drawing primitives (formerly called "primDraw" or something like that). If that functionality comes out in the form of a different library (perhaps a certain awesome one that Hoeloe's been working on, one that I don't know whether or not it's been shared here on the forum yet and thus am going to refer to in an annoyingly-vague manner) or new additions to lunalua, I'll probably end up using that instead... otherwise y'all are welcome to take graphX and flesh it out more. I'll probably finish the library myself eventually if nobody does anything about primitive drawing, but it's not a high priority.


...With all of that said, I'm taking another break from cinematX to focus on school and catch up on other commitments I didn't make enough progress on during my summer vacation. In particular I've been taking too long with redoing Phantasmaburbia's graphics, I need to have all that finished within the next month so I can focus on getting it into the game and catch any resulting graphical bugs late September/early October (see the "Art and stuff" link in my sig for more info). Once Phanta launches on Steam and I manage to get on top of/finished with my schoolwork, I'll get back to working on cinematX.

[Rixithechao]

As I mentioned in the A2XT Episode 2 discussion thread, I've decided I'm going to try and fix up cinematX for the Ep. 2 devkit. While I'm at it, I think I'll throw in some of the stuff I was saving for v0.1.0 as well.

I'm going to see what I can get done and committed to the Github repo by/during Labor Day weekend, after which I'll go back to not working on this thing until November. For the time being, I went and gave Actors a few functions to select and follow the closest instance of a given block or NPC type within a variable radius. Eventually I'd like to make them be able to carry, drop and throw items as well.

[Rixithechao]

Really though, if someone doesn't end up making a b-ball minigame out of this I'm going to be a very sad bananabean.

EDIT:
Not only will Actors be able to pick up other NPCs, but they will now be able to steal whatever the player's carrying if you allow it. Please abuse this new functionality responsibly.

[Rixithechao]

Arright MaGLX2 peeps, if you used cinematX for the contest please either send me a copy of your level via PM or test your level with this package and post the results in this thread. See the readme file for installation instructions and other info.

https://drive.google.com/file/d/0B-w323 ... sp=sharing

[Rixithechao]

So I've been squashing bugs, adding new features and improving the usability of cinematX and its companion libraries for quite a while, and now a stable 0.8 release is in sight... maybe sometime in the spring.

The documentation is in need of a significant overhaul and a new sample episode is definitely in order. And there's a lot more functionality to cover this time around:

• Cutscenes and coroutines
• Dialogue
• Actor interaction
• Sidequests
• Followers
• Combat
• Camera control
• Bosses
• Races
• textblox
• graphX
• Custom menus

Between the cinematX suite, school, A2XT and work outside of the talkhaus I'm really going to have my hands full this year, so I figured I'd ask... how would y'all feel about the new sample episode being a collab?

It won't be a full-length 8-world game, just a series of small levels/tech demos each showcasing one of the things listed above... maybe a few longer levels utilizing several of them as well. So around 12-16 levels, probably connected by a hub.

Right now I'm just looking to see how many peeps would be interested in such a project, so please post here or let me know on Skype or via PM if you'd like to contribute when the time comes, even if you're not that familiar with the cinematX suite or even LunaLua in general; if there's enough interest, chances are you'll be able to work with someone who has more scripting knowhow.

[Rixithechao]

Over the last few days I've been working on adding camera zooming functionality to an outdated copy of cinematX, and as you can see above, not only is it working pretty dang well now but I went ahead and added Smash Bros-style multi-object tracking with auto-zooming as well for the heck of it! After I've copied the new camera code over to the latest version of the cinematX source (which I won't be able to do until next Monday due to IRL stuff) I won't have all that much left to do before cinematX 1.0. No, not 0.8. Not 0.9. cinematX 1.0.

The original goal of the library was to make something that would be able to replicate A2XT Episode 1's pre-rendered Flash-animated moments in SMBX. The zooming was the last big feature for that, so I consider the library pretty much complete now. That's not to say there isn't anything more I can add, just that this will be the first full version of the library. And I can't guarantee there'll be that many updates after 1.0, but 1.0 most likely won't be the last version.

So here's the rough to-do list for now:
- Copy over the updated camera functionality
- Replace the pan functions with a single moveCamera function with named arguments
- Fix the coroutine abortion bug
- Fix up any other remaining bugs
- Release cinematX 1.0
- Release the inevitable 1.1 patch
- Finish the documentation
- Start work on the new sample episode