(shouting)

LunaLua Offical Thread

The second SMBX collab!

Shall I stream some LunaLua live development?

Yes
23
92%
No
2
8%
 
Total votes: 25

User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: Presenting: Lunadll for Lua!

Post by Hoeloe »

Kevsoft wrote:
Hoeloe wrote:until I can get a debug mode though
... something like that: https://wiki.eclipse.org/Koneki/LDT/Use ... inspection?

Koneki (Eclipse for Lua) allows attaching a debugger. It might be possible to add such thing for LunaLua.
Oh no, that's not what I meant. I can attach a debug environment without too much of a problem, but it doesn't work for my specific use case. You see, I'm working on the library for collision volumes. When developing and using this library, it's often necessary to synchronise the collision code with what's going on on the screen. The best way to do this is by being able to see the collision volumes, so any problems become immediately apparent.

The issue is that SMBX currently has no tools for drawing to the screen other than placeSprite, which only allows a fixed-size, non-transparent bitmap to be drawn over. I'm waiting for the OpenGL renderer so I can access OpenGL drawing commands and draw arbitrary size and shaped polygons to the screen, which will allow me to visualise the colliders in-game.
Image
Image
Image
Image
Image
User avatar
Kevsoft
LunaLua Master Developer
Posts: 83
Joined: 9 years ago

Re: Presenting: Lunadll for Lua!

Post by Kevsoft »

Hoeloe wrote:...
Ah I see what you mean, but I will think about implementing the Koneki debugger anyway. It seems useful for me.
User avatar
Rednaxela
Maker of Shenanigans
Posts: 897
Joined: 10 years ago
Pronouns: they/them
https://rednaxela.talkhaus.com

Re: Presenting: Lunadll for Lua!

Post by Rednaxela »

By the way, good news! The mushroom-in-lava bug is now patched by LunaDLL!

Thanks to Horikawa for getting the test level set up there, and thanks to Kevsoft for doing the detailed research into what exactly was happening during the bug, which led me make a little assembly code patch to fix it, which Kev has now tested and is in place in the LunaDLL code :)
User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: Presenting: Lunadll for Lua!

Post by Hoeloe »

I went ahead and attempted to implement polygon collision. I think I have it working! I'm not going to release it until I've got the OpenGL renderer to verify that it's actually working, though, but my preliminary tests appear to.
If anyone is interested in the implementation, it's fairly neat. It only uses two kinds of collision detection, Poly-Poly and Poly-Point. Poly-Point is easiest, that works by iterating over each edge in the polygon and calculating the winding number at the point by working out which side of each edge the point lies on. If the winding number is greater than 0, then the point is inside the polygon.

As for Poly-Poly collision, this gets fairly expensive. Arbitrary polygon-polygon collision is always a problem, so I've opted for a fairly expensive method, relying on the fact that we won't be using hundreds of edges in each polygon. It first checks the bounding boxes of both polygons, to ensure we don't do a tonne of calculation for no reason. It then checks if a single point in each polygon is inside the other (this accounts for the cases where one polygon is entirely inside the other). Then it compares all the edges of one polygon with all the edges of the other polygon (hooray for O(n^2)!), and returns true if any pair of edges is intersecting. If all of these tests fail, then the polygons are not intersecting.

For box and circle collisions, it just converts them into approximate polygons and runs the Poly-Poly collision test.
Image
Image
Image
Image
Image
Zia Satazaki
Floof Incarnate
Posts: 28
Joined: 14 years ago
Pronouns: she/they

Re: Presenting: Lunadll for Lua!

Post by Zia Satazaki »

What about Separating Axis Theorem? It's what box2d uses internally, and I have an implementation in my Platinum engine if you'd like to give it a look: http://github.com/zetaPRIME/Platinum
User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: Presenting: Lunadll for Lua!

Post by Hoeloe »

JVyrn wrote:What about Separating Axis Theorem?
The reason I didn't want to use that is because it only applies for convex shapes (as do most collision algorithms). Since the primary purpose of this library is accessibility, I decided to go with a solution that allows arbitrary polygons, rather than forcing the constraint of convex ones.

In theory, I could adapt the SAT by splitting non-convex polygons into a series of convex ones, which would allow the same functionality, but to be honest, the difficulty of implementation of that is disproportionate to the usefulness of the result it provides in this circumstance.

Of course, I can always change the implementation later if it proves necessary. Initial tests suggest that for reasonably simple polygons, there shouldn't be any noticeable slowdown.
Image
Image
Image
Image
Image
User avatar
Kevsoft
LunaLua Master Developer
Posts: 83
Joined: 9 years ago

Re: Presenting: Lunadll for Lua!

Post by Kevsoft »

Thanks Hoeloe for that great idea :3


TiKi
Posts: 709
Joined: 11 years ago

Re: Presenting: Lunadll for Lua!

Post by TiKi »

Does anyone use Lunalua and GameMaker? I have a few questions to ask. As a heads up, it's mainly me wondering why the latter seems easier for me to use.
User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: Presenting: Lunadll for Lua!

Post by Hoeloe »

I had an idea for a level for A2XT recently, but I think it would be easiest to do with some Lua shenanigans on the section backgrounds. I don't believe we currently have access to those, but I could do what I have in mind really neatly if I could control the animation frame of the section backgrounds. It would be good to be able to change the size of them too, for customisation purposes.
Image
Image
Image
Image
Image
User avatar
Kevsoft
LunaLua Master Developer
Posts: 83
Joined: 9 years ago

Re: Presenting: Lunadll for Lua!

Post by Kevsoft »

TiKi wrote:Does anyone use Lunalua and GameMaker? I have a few questions to ask. As a heads up, it's mainly me wondering why the latter seems easier for me to use.
GameMaker is a whole Program for making games, while LunaLua is only a script language with access to SMBX memory. You should compare GameMaker with PGE instead.
Hoeloe wrote:I had an idea for a level for A2XT recently, but I think it would be easiest to do with some Lua shenanigans on the section backgrounds. I don't believe we currently have access to those, but I could do what I have in mind really neatly if I could control the animation frame of the section backgrounds. It would be good to be able to change the size of them too, for customisation purposes.
I am bit behind with other stuff, but when I have time then, I will get into that.
User avatar
Wohlstand
Moondust and TheXTech developer
Posts: 186
Joined: 10 years ago
First name: Vitaly
Pronouns: he/him/his
Location: Moscow, Russia

Re: Presenting: Lunadll for Lua!

Post by Wohlstand »

Kevsoft wrote:...You should compare GameMaker with PGE instead.
Anyway, GameMaker and PGE are different systems with DIFFERENT purposes:
- GameMaker like development studio for programming language where you creating any random games.
- PGE technically is fully compatible alternate implementation of SMBX Engine, but with enhancements and new features which unavailable in original SMBX engine, but unlike SMBX, PGE going to give ability make platform games of any universes and doesn't closing to Mario universe unlike SMBX.
User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: Presenting: Lunadll for Lua!

Post by Hoeloe »

So, I've realised that the raocoin library is incredibly out of date, and a quick look over it has also made me realise that it's not fully compatible with the multipoints library. The only way I can feasibly make them compatible, without making it require multipoints, is a test to see if multipoints is available. Is there an API function which will return nil if the given API is loaded, and otherwise return the API reference?

Also, wasn't there a plan to implement a safe loadImage function, that didn't require an image ID to be passed to it, but just assigned the image to a free one and returned the ID? That's a million times more sensible than what we have at the moment, because library compatibility is extremely difficult to ensure, particularly if you require a varying number of images. It would be much more sensible to write:

Code: Select all

local image = loadImage(path,alpha);
than the current method:

Code: Select all

local image = 858477;
loadImage(path,image,alpha);
I'm asking this now because I'm re-writing the raocoin library from scratch, and I want to allow you to register multiple currencies, rather than forcing it to use dragon coins. For that, though, I also need a variable number of UI elements, which causes problems when I can't guarantee free slots.

Theoretically, I could implement such a system in Lua alone, but it would require that all image IDs are loaded using the library, and any that aren't will break it.
Image
Image
Image
Image
Image
User avatar
Kevsoft
LunaLua Master Developer
Posts: 83
Joined: 9 years ago

Re: Presenting: Lunadll for Lua!

Post by Kevsoft »

About the whole image thing, I want to wait until the opengl renderer is out. Because with the base of this, we will rewrite the custom image manager anyway.

And about the loaded API thing: There is a function called "isAPILoaded([table or string] api)".
User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: Presenting: Lunadll for Lua!

Post by Hoeloe »

Kevsoft wrote:About the whole image thing, I want to wait until the opengl renderer is out. Because with the base of this, we will rewrite the custom image manager anyway.

And about the loaded API thing: There is a function called "isAPILoaded([table or string] api)".
Fair enough. That makes sense.

As for the API, I've opted for a different approach anyway. The old version of the raocoin library was only minimally customisable. The new one I'm building will allow you to not only register a currency on any NPC, but also to determine exactly when this currency is saved to the disc, by calling "save()" on the currency object. It also supplies you with an event called "raocoin.onCollect", which you can use to run code when you pick up a currency object.
Image
Image
Image
Image
Image
User avatar
Rednaxela
Maker of Shenanigans
Posts: 897
Joined: 10 years ago
Pronouns: they/them
https://rednaxela.talkhaus.com

Re: Presenting: Lunadll for Lua!

Post by Rednaxela »

I agree the hardcoded image IDs thing kind of sucks the way it is now. Also, I'm thinking that at the same time as we add an API that doesn't require the manually assigned IDs, we might as well make the new version of that API capable of loading PNGs with alpha channel, instead of that funky "BPMs only, and a specific color becomes transparent" thing. I already have utility code for loading such images in place after all.
User avatar
Wohlstand
Moondust and TheXTech developer
Posts: 186
Joined: 10 years ago
First name: Vitaly
Pronouns: he/him/his
Location: Moscow, Russia

Re: Presenting: Lunadll for Lua!

Post by Wohlstand »

Rednaxela wrote:I agree the hardcoded image IDs thing kind of sucks the way it is now. Also, I'm thinking that at the same time as we add an API that doesn't require the manually assigned IDs, we might as well make the new version of that API capable of loading PNGs with alpha channel, instead of that funky "BPMs only, and a specific color becomes transparent" thing. I already have utility code for loading such images in place after all.
Anyway you can append SDL_Image (and when you will get SDL_Surface which you can convert into ARGB texture) or libpng directly to load decode png into ARGB texture
User avatar
Rednaxela
Maker of Shenanigans
Posts: 897
Joined: 10 years ago
Pronouns: they/them
https://rednaxela.talkhaus.com

Re: Presenting: Lunadll for Lua!

Post by Rednaxela »

Wohlstand wrote:Anyway you can append SDL_Image (and when you will get SDL_Surface which you can convert into ARGB texture) or libpng directly to load decode png into ARGB texture
Regarding loading PNGs, I already have code in LunaDLL that does the job using the Windows Imaging Component. No need for SDL_Image or libpng.

About SDL_Surface and it's support for converting into textures with SDL, the way I need to set up the OpenGL context (i.e. for directly rendering to a HDC (that SMBX itself has already allocated) using OpenGL) doesn't really allow me to use SDL's OpenGL support so far as I can tell. What I have using WGL and GLEW calls is working just fine in any case.
Last edited by Rednaxela 9 years ago, edited 1 time in total.
User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: Presenting: Lunadll for Lua!

Post by Hoeloe »

On a totally unrelated note, I'm experimenting with using printText in world space rather than screen space. In theory, this should be very easy, but in practice, as far as I know there's no way to get the actual screen boundaries. The player's "screen" variable doesn't account for section boundaries, so just causes things to spill off the end of sections. I think I've got the horizontal transformation working, but the vertical one is giving me trouble.

EDIT: I think I've got it! This function SHOULD give accurate screen boundaries, and allow for transformation between world and screen coordinates:

Code: Select all

function getScreenBounds()
	local b = { left = player.x-400+player.speedX, right = player.x+400+player.speedX, top = player.y-260+player.speedY, bottom = player.y+340+player.speedY };
	
    local sect = Section(player.section);
    local bounds = sect.boundary;

	if(b.left < bounds.left - 10) then
		b.left = bounds.left - 10;
		b.right = b.left + 800;
	end
	
	if(b.right > bounds.right+10) then
		b.right = bounds.right+10;
		b.left = b.right - 800;
	end
	
	if(b.top < bounds.top+10) then
		b.top = bounds.top+10;
		b.bottom = b.top + 600;
	end
	
	if(b.bottom > bounds.bottom+10) then
		b.bottom = bounds.bottom+10;
		b.top = b.bottom - 600;
	end
	
	return b;
	
end
Image
Image
Image
Image
Image
User avatar
Wohlstand
Moondust and TheXTech developer
Posts: 186
Joined: 10 years ago
First name: Vitaly
Pronouns: he/him/his
Location: Moscow, Russia

Re: Presenting: Lunadll for Lua!

Post by Wohlstand »

Rednaxela wrote:
Wohlstand wrote:Anyway you can append SDL_Image (and when you will get SDL_Surface which you can convert into ARGB texture) or libpng directly to load decode png into ARGB texture
Regarding loading PNGs, I already have code in LunaDLL that does the job using the Windows Imaging Component. No need for SDL_Image or libpng.

About SDL_Surface and it's support for converting into textures with SDL, the way I need to set up the OpenGL context (i.e. for directly rendering to a HDC (that SMBX itself has already allocated) using OpenGL) doesn't really allow me to use SDL's OpenGL support so far as I can tell. What I have using WGL and GLEW calls is working just fine in any case.
Anyway WIC works slower than manual parsing of PNG format.

I meant manual conversion from SDL_surface into necessary format by manual fetching of pixel array and constructing of necessary format to get it working with SMBX.
User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: Presenting: Lunadll for Lua!

Post by Hoeloe »

Wohlstand wrote: I meant manual conversion from SDL_surface into necessary format by manual fetching of pixel array and constructing of necessary format to get it working with SMBX.
That is... not really a good idea. When it comes to textures, you want to avoid just fetching the pixel array as much as you can, because unless you're pushing it through the GPU, that's going to be an incredibly slow operation.
Image
Image
Image
Image
Image
User avatar
Wohlstand
Moondust and TheXTech developer
Posts: 186
Joined: 10 years ago
First name: Vitaly
Pronouns: he/him/his
Location: Moscow, Russia

Re: Presenting: Lunadll for Lua!

Post by Wohlstand »

Hoeloe wrote:
Wohlstand wrote: I meant manual conversion from SDL_surface into necessary format by manual fetching of pixel array and constructing of necessary format to get it working with SMBX.
That is... not really a good idea. When it comes to textures, you want to avoid just fetching the pixel array as much as you can, because unless you're pushing it through the GPU, that's going to be an incredibly slow operation.
fetching of pixel array must be made once, and after everything going with fastest way. The slow operation is double-fetching of pixel array when you do bitwise operation to draw masked images. The alpha-blending is much faster and you do fetch of pixel array once [anyway OpenGL natively doing than on GPU]
User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: Presenting: Lunadll for Lua!

Post by Hoeloe »

Wohlstand wrote: fetching of pixel array must be made once, and after everything going with fastest way. The slow operation is double-fetching of pixel array when you do bitwise operation to draw masked images. The alpha-blending is much faster and you do fetch of pixel array once [anyway OpenGL natively doing than on GPU]
Not necessarily. There's a difference between fetching the texture and fetching the pixel array. You have to push the texture to the GPU (via OpenGL) at least once, but that's not necessarily the same thing as pushing the pixel array down the pipeline.

Having said that, grabbing the pixel array and just pushing it down the pipeline isn't really a problem, it's only if we start messing with it in the interim that we'll have performance issues.


EDIT: Also, the code I posted on the last page for fetching the screen doesn't work. It only applies when Mario is small.

EDIT EDIT: This appears to work now, it takes into account player height this time:

Code: Select all

function getScreenBounds()
	local h = (player:mem(0xD0, FIELD_DFLOAT));
	local b = { left = player.x-400+player.speedX, right = player.x+400+player.speedX, top = player.y-260+player.speedY, bottom = player.y+340+player.speedY };
	
    local sect = Section(player.section);
    local bounds = sect.boundary;

	if(b.left < bounds.left - 10) then
		b.left = bounds.left - 10;
		b.right = b.left + 800;
	end
	
	if(b.right > bounds.right - 10) then
		b.right = bounds.right - 10;
		b.left = b.right - 800;
	end
	
	if(b.top < bounds.top+40-h) then
		b.top = bounds.top+40-h;
		b.bottom = b.top + 600;
	end
	
	if(b.bottom > bounds.bottom+40-h) then
		b.bottom = bounds.bottom+40-h;
		b.top = b.bottom - 600;
	end
	
	return b;
	
end
Image
Image
Image
Image
Image
User avatar
Kevsoft
LunaLua Master Developer
Posts: 83
Joined: 9 years ago

Re: Presenting: Lunadll for Lua!

Post by Kevsoft »

It's something WIP. If you want a copy of the current LunaLua, then catch me on the IRC.

Anyway, I want to add more support to LDT, as also adding code templates for LDT to speed up developing for advanced user. Eclipse is just awesome.
User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: Presenting: Lunadll for Lua!

Post by Hoeloe »

Okay, I think I'm going to wait until v0.7 to finish up raocoinv2. It seems pointless to release it as it is when it's just going to need changing for the OpenGL stuff, and I may want to make use of the whole onLevelExit thing, too, if it allows us to determine how the level was exited (death, quit through menu, or stage win).
Image
Image
Image
Image
Image
User avatar
Rednaxela
Maker of Shenanigans
Posts: 897
Joined: 10 years ago
Pronouns: they/them
https://rednaxela.talkhaus.com

Re: Presenting: Lunadll for Lua!

Post by Rednaxela »

Hoeloe wrote:when it's just going to need changing for the OpenGL stuff
Well I mean... it will all be 100% backwards compatible... though that'll be the time to set up a nicer API yeah.
Post Reply