cinematX - 1.0 is on its' way

[Rixithechao]

Okay, given these issues it's clear that cinematX needs a better way to control which NPCs have Actors generated for them.
I have an idea on how to implement this so I'll try and get a patch out sometime this weekend.

[Hoeloe]

It looks like the SMB3 Bob-omb has an interesting quirk in SMBX. When placed outside section boundaries (even if the section is not your current one), it reverts all its data to 0. This overwrites the CinematX ID, and causes strange bugs to occur. Unfortunately, there's not much I can do about this, because it's out of Lua's control.

[Rednaxela]

I haven't looked into it myself yet, but just wondering... what's the reason for loading CinematX in mainV2.lua? To me it doesn't seem like a good idea (even when the current performance problems are solved) to load something like CinematX globally instead of only in levels that use it.

[Rixithechao]

It was a necessity at one point for a reason I can't even remember.
I just checked and it's not anymore.
Wow, I'm a dumb.
EDIT: As mentioned in the MaGL thread, removing that line breaks the town sample level.

[Hoeloe]

Thought you might like this bit of code. It takes a string, and pads it out with spaces to CinematX can display it properly.

Code: Select all

function formatCinematXString(str)
	local tl = str;
	local hd = "";
	local i = 1;
	while(string.len(tl)>42) do
		local split = wrapString(tl,42);
		split.hd = split.hd:gsub("^%s*", "")
		split.tl = split.tl:gsub("^%s*", "")
		local c = 42;
		if(i > 1) then c = 43; end
		while(string.len(split.hd) < c) do
			split.hd = split.hd.." ";
		end
		hd = hd..split.hd;
		tl = split.tl;
		i = i + 1;
	end
	return hd..tl;
end

function wrapString (str, l)
		local head = "";
		local tail = "";
		local wrds = {}
		local i = 0;
		for j in string.gmatch(str, "%S+") do
			wrds[i] = j;
			i = i + 1
		end
		i = 0;
		while(wrds[i] ~= nil) do
			local newHd = head.." "..wrds[i];
			if(string.len(newHd) <= l) then
				head = newHd;
				i = i + 1
			else
				break;
			end
		end
		
		while(wrds[i] ~= nil) do
			tail = tail.." "..wrds[i];
			i = i + 1
		end
		
		return { hd = head, tl = tail };
	end

[Sorel]

According to the PGE wiki, the functions freezePlayerInput () and unfreezePlayerInput () aren't working currently, but the wiki got last updated on february 4th. Is it working now or is it still disabled?

[Hoeloe]

According to the PGE wiki, the functions freezePlayerInput () and unfreezePlayerInput () aren't working currently, but the wiki got last updated on february 4th. Is it working now or is it still disabled?

I believe it's still disabled. How to disable the player input is currently an unsolved problem, and various hacked around solutions have been attempted. My level, for example, makes a copy of the player's location when the cutscene starts, and continuously resets the player to that location during the cutscene. This disables movement, but doesn't stop the player from jumping, ducking, attacking or walking (it just means that jumping and walking don't move the player).

This is still being looked into, but there's no definitive version yet, so those functions are still disabled.

[Sorel]

Well, that is unfortunate. I'll see what I can do to prevent movement, evn if it means using an event that blocks everything...

[Hoeloe]

Well, that is unfortunate. I'll see what I can do to prevent movement, evn if it means using an event that blocks everything...

That's part of the problem. The obvious way to freeze player input is to use a SMBX event that forces an input that does nothing (e.g. holding Run without any directions). The problem is that this interferes with the CinematX cutscene inputs, making you unable to progress cutscenes.

[Rednaxela]

The obvious way to freeze player input is to use a SMBX event that forces an input that does nothing (e.g. holding Run without any directions). The problem is that this interferes with the CinematX cutscene inputs, making you unable to progress cutscenes.

I don't have time to test this right now, but I find myself wondering... whether the SMBX cheat buffer is also frozen when a SMBX event freezes player input. If not... perhaps one could use the cheat buffer for reading the keys that progress cutscenes... Though... unless somebody knows the memory address of keybindings that'll only be super usable with default keybindings.

[Hoeloe]

The obvious way to freeze player input is to use a SMBX event that forces an input that does nothing (e.g. holding Run without any directions). The problem is that this interferes with the CinematX cutscene inputs, making you unable to progress cutscenes.

I don't have time to test this right now, but I find myself wondering... whether the SMBX cheat buffer is also frozen when a SMBX event freezes player input. If not... perhaps one could use the cheat buffer for reading the keys that progress cutscenes... Though... unless somebody knows the memory address of keybindings that'll only be super usable with default keybindings.

It isn't. I already implemented this in another version of CinematX, but it's imperfect. For one thing, as you say, it won't allow for rebinding of keys. It also has the issue of only using basic key functionality, which means that holding a key down and pressing it repeatedly are indistinguishable actions, which causes problems when you want to register individual presses of the key.

[Rixithechao]

Actually, hmm... if we reset the cheat buffer's string every frame, could we theoretically set up a basic state machine?
Keep track of the key's current state and the buffer's previous string and change the key state from "up" to "press" to "down" to "release" based on whether the cheat buffer's current string matches the stored previous string.

I'll have to try that on Thursday.

[Hoeloe]

Actually, hmm... if we reset the cheat buffer's string every frame, could we theoretically set up a basic state machine?
Keep track of the key's current state and the buffer's previous string and change the key state from "up" to "press" to "down" to "release" based on whether the cheat buffer's current string matches the stored previous string.

I'll have to try that on Thursday.

It won't solve any of the problems. The response you can get is very limited. You can only check "is a key being pressed?", but if you hold the key down, this is true, false for about 1 second, then repeatedly toggling true and false. Even if you reset the buffer, it doesn't reset the key state, so it just means you'd get, on alternating frames: "x" "" "x" "" "x"... etc. From this, there's no concrete way of determining when the key is released, since this state is in parallel to the main thread, and you may end up with something more like: "xx" "" "x" "xx" "" ""... etc.

[Rixithechao]

It won't solve any of the problems. The response you can get is very limited. You can only check "is a key being pressed?", but if you hold the key down, this is true, false for about 1 second, then repeatedly toggling true and false. Even if you reset the buffer, it doesn't reset the key state, so it just means you'd get, on alternating frames: "x" "" "x" "" "x"... etc. From this, there's no concrete way of determining when the key is released.

...Oh, right. D'oh. >_<

[Kevsoft]

Maybe the native SMBX keyboard buffer helps? I am not sure, if you can overwrite the native keyboard buffer, or if it is overwritter before lua can interfere it.

[Hoeloe]

Maybe the native SMBX keyboard buffer helps? I am not sure, if you can overwrite the native keyboard buffer, or if it is overwritter before lua can interfere it.

If we can get access to SMBX's input buffer (for control, not cheats), we should be able to cache the values and give them to Lua without SMBX interfering. That would allow us to block input using a SMBX event, and use the input values passed to Lua to control cutscenes. This is the ideal scenario, but it's not simple to achieve.

[Kevsoft]

Dangit, I just noticed, that SMBX doesn't have a Input buffer, the only thing I could do is to get very low-level and hook the keyboard function, where SMBX gets its keyboard state.

[Hoeloe]

Dangit, I just noticed, that SMBX doesn't have a Input buffer, the only thing I could do is to get very low-level and hook the keyboard function, where SMBX gets its keyboard state.

Wherever SMBX gets its input from is the ideal place to get ours, because it then retains consistency with the main game.

[Rixithechao]

NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNEW UPDATE (v0.0.7)

CHANGES:

- The random crashes from NPC deaths should be fixed now
- Added Actor:getMem and Actor:setMem, which work just like the NPC:mem functions
- Added Actor.invincible
- Added Actor.onGround (read-only)
- Finished implementing the levelStartScene variable
- More info is logged to the console now
- I think I added more stuff but I can't remember it at the moment
- Praise be to the grocery gods for easy mac

[Rednaxela]

Hey Rocky, just took a quick look at the changes in 0.0.7 and noticed a minor problem based on your new usage of a memory offset I've been playing round with recently myself.

Code: Select all

		-- Update invincible
		if  (self.invincible == true)  then
			self:setMem (0x156, FIELD_WORD, 1)
		end

The engine decrements the invincibility frame timer that's at 0x156 before it checks whether it's non-zero, meaning that if you want to trigger invincibility during the next frame the engine runs, you need to set a value > 1, not > 0

[Rixithechao]

Ah, thanks for catching that! The > 1 thing applies to a couple other things as well so I should probably take that as a rule of thumb from now on just to be safe.

[Hoeloe]

There is a bug in cinematX that causes animation and cutscenes to be entirely broken. This has been fixed, but the current download (0.0.7) still contains the bug. For now, please use this version of cinematX.lua, which has the bug fix included:

Download cinematX.lua (0.0.7patch)

[Rixithechao]

For folks wondering what the status is on cinematX and animatX, here's a quick repost from the companions video.

Soooo, is the project abandoned or sth?

Sorta kinda, I guess.

In the past couple months a few other programmers on the talkhaus have started working with LunaDLL and LunaLua, and their accomplishments severely outclass cinematX. They came up with a much more efficient NPC wrapper class system, custom colliders... they even figured out how to spawn NPCs directly from code and now they're overriding SMBX's rendering system to include PNG support and who knows what else.


cinematX is based on clunky, outdated methods and needs to be updated, but I've been hesitant to jump back into working on it for a bunch of dumb personal reasons -- I'm overwhelmed by all of this new stuff and I'm not sure where to start. My Lua skills are rusty for not working on it for so long. I spent a lot of time working on troubleshooting, debugging and writing documentation for cinematX only for it to still be buggy and inaccessible by the end of the contest and few people to actually use it because of that.

I started working on a program to help with formatting SMBX sprite sheets for cinematX animations, but with all the new developments I'm wondering if even that will be outdated by the time I'm done with it.


TL;DR version:

I want to get back to working on it but keep putting it off due to personal anxiety and stuff about it, but I'm fully aware that the longer I stay away from it the harder it'll be and blargh

Sorry for the wall of text. I'll add some relevant links to the video description so you'll be able to follow this stuff more closely.

So yeah, not officially abandoned yet but I'm having trouble mustering up the motivation to jump back in. Maybe this'll change once I'm done with the semester (currently week 13 out of 16, so not long now).

[Rednaxela]

I've found a few bugs in the current version of cinematX that prevent some existing cinematX levels from working correctly.

First and foremost:

Code: Select all

							-- Store key for use in getNPCFromKey() if parsed
							if (parsedKey ~= nil) then
								cinematX.npcMessageKeyIndexes[parsedKey] = i

Uhh... "i" is undefined. This will always fail ,thus message key based actors don't work at all. That kind of breaks an awful lot of cinematX levels. Fix this by changing the last line to "cinematX.npcMessageKeyIndexes[parsedKey] = uid"[/s]
EDIT: Turns out this one above was what Hoeloe fixed above, but I didn't realize because I had been assuming Github (which is what the wiki any everything links to, and for most helper libraries the wiki is the place to ensure you get the latest version...) had all of Hoeloe's most recent fixes. This assumption was wrong. The below two fixes are still new though.

Secondly:

Code: Select all

			--Assign a new unique ID to the NPC (this applies to all NPCs, not just CinematX enabled ones.
			if (uid == 0  and  isDying == false)  then
				uid = cinematX.npcCount;

The above has a problem because cinematX.npcCount starts at 0 (incremented after this), and yet reading 0 from the UID field is considered to mean that no UID has been assigned yet. This makes cinematX fail to properly create and actor for the first NPC object returned by npcs() at the start of the level. Fix this by changing the last line there to "uid = cinematX.npcCount + 1;"

Thirdly and by far least importantly:

Code: Select all

	function cinematX.runCoroutine (func)
		-- This function is just a quick wrapper to start a coroutine.
		
		local co = coroutine.create (func)
		return coroutine.resume (co)
	end

This one is probably less clear but... there is old sample code for cinematX around that calls cinematX.runCoroutine() with no argument, and various levels have followed that pattern. As such, in order to not throw errors (though silently, because cinematX unfortunately swallows errors within coroutines, and generally harmlessly because the old examples put this at the end of a coroutine for some reason), this function should probably contain an "if (func ~= nil) then" check.

A patched version of cinematX.lua is attached.

[Hoeloe]

The above has a problem because cinematX.npcCount starts at 0 (incremented after this), and yet reading 0 from the UID field is considered to mean that no UID has been assigned yet. This makes cinematX fail to properly create and actor for the first NPC object returned by npcs() at the start of the level. Fix this by changing the last line there to "uid = cinematX.npcCount + 1;"

Possibly would be more sensible to just bump up the line that increments the npcCount variable:

Code: Select all

				uid = cinematX.npcCount;
				v:mem (cinematX.ID_MEM, FIELD_WORD, uid);
				cinematX.npcCount = cinematX.npcCount + 1;

Becomes:

Code: Select all

				cinematX.npcCount = cinematX.npcCount + 1;
				uid = cinematX.npcCount;
				v:mem (cinematX.ID_MEM, FIELD_WORD, uid);

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

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.