Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics


A member registered Mar 09, 2016 · View creator page →

Creator of

Recent community posts

thanks! Wasn’t trying to do anything new or different or anything, at least not this time around, this was a game dev project for YouTube so I’m glad to hear you think it reads well.

There is an available upgrade where killing a foe immediately after dying will revive you, but if it happened after the dialog showed up there’s probably something wrong with it, I’ll have to investigate it later.

The colors are indexed by counting all of the (unique) colors in the image and putting them in order. This can’t be done in a shader and has to be done ahead of time, but mapping the color onto the index can be done in O(1). Jon’s works by searching the palette for a matching color (or an almost-matching color), which is much slower but is usually good enough.

Getting the palette of a sprite at runtime isn’t something Lorikeet does (nor do I have any interest in doing so), though if you really want to do that there’s this one that Jon made. The color index is stored in the grayscale value. Look into how old video game consoles stored sprite color before the days of RGBA.

If you want to apply an additional effect after the palette lookup, modify the final gl_FragColor value.

“Why are all of the handwriting fonts so clean?” was literally the question that led me to this, lol. Nice.

Do you have a preferred way of being credited? If not I’ll just include a link to this Itch page.

lol, that would do it

Somewhat curious in how you calculated the odds of the crash…

I haven’t been able to replicate the issue (and the line of code in question *should* contain a safeguard against problems like this happening). Can you find an exact way to reproduce it?

For what it’s worth, an official particle editor has been announced by GameMaker on the roadmap, and when that comes out in a few months I’ll probably be retiring this one.

Have fun with it!

The type at the bottom is something that’s in the development version that I don’t include in the “official” version (yet), it’s related to this. It doesn’t have an effect on how files are loaded.

I think I’ve fixed it, if you go into Preferences and make sure Combine OBJ Vertex Colors and Combine OBJ Submeshes are turned off that’ll prevent the program from overwriting the vertex color with the material color when you import files. I’ve also uploaded an updated version where vertex colors are blended with material colors instead of overwritten by them. Hopefully that’s the end of the problems.

Fixed the viewer settings bug. On that note, do you have “view vertex colors” turned on in the settings? Turning them off will obviously not show the vertex colors.

Works for me. Download it again to make sure you got the current version.

Can you send me the file? The ones I’ve tried work.

Okay, let’s see.

If you open the obj in notepad, does it show six values after every “v” line instead of three? Also, you tried it with the beta version of Penguin instead of the old one, right?

Actually, I suppose while I’m at it I might as well see if I can get the transparency to play nicely with Crocotile models too.

Okay, it seems to be working. I uploaded a “beta” version of the program ( in the downloads), let me know if it works and I’ll promote it to the regular version.

The obj spec doesn’t officially support vertex color - although there are a few “unofficial” specs, which it seems that Crocotile actually uses. I’ll try to get back to you on that in a few hours.

I’m making this for free. I’ll get to it when I get to it.

Yeah, now that the rest of the program is mostly finished I should probably see about working this out at some point.

Should just be able to do group.AddTabs(row, …) again, it appends the new tabs onto the end of the row without clearing existing ones.

Oh god did it break again.

Should be interesting!

that would require a Linux build anyway though

I could, depends on how much of a need for it there is though. Ideally I don’t encourage people to continue using 32-bit GameMaker :P

…how on earth did you know this has been on my mind a lot in the last week or so

Thanks, glad you had fun with it all! I do eventually want to add a few more things eventually such as some kind of persistent bonuses between levels, not sure how soon I’ll get on that though.

The original thing that this is based on actually does have a dropdown menu system in place, but I didn’t carry it over to here (yet) because I’m not really a fan of how it works. A dropdown element would probably honestly look a lot like that, minus the ability to unfold.

Trees could theoretically be done already by combining a bunch of buttons and text labels and whatnot… but have an element dedicated to that would probably be vastly preferable.

I definitely need to do drop-down lists, a few people have requested them now. I think you’re the first person I’ve seen mention trees/foldable regions, but I can see those being hugely useful too.

Yeah, the goal in that one was a bit vague. If I’d had more time I would have liked to add a few more large objects to help orient yourself.

Hmm, I’d initially done that intentionally but honestly I can see how that would be more annoying than anything else. I’ve disabled changing course during transit, new version should be good now!


mouse_x and mouse_y are the mouse’s position relative to the room, so if you make use of views and cameras it may start to conflict (although if it works for you, that’s all that matters).

The device mouse functions are probably the solution that should work in pretty much all cases, since they’re designed to take the GUI layer into account - I’ll play around with that next chance I get; as long as nothing bad happens I might make that the default.

If absolutely necessary I could make the mouse position value a macro that the user could change depending on their needs, although I doubt it would come down to that.

Oh dear, thanks for reminding me. This should do it.

I also saw you left a few comments on Emu; I’ll try to work on that some time this week, there are a few other changes I need to make over there as well.

Well, it looks like I’ve got my work cut out for me, lol.

I’ll try to get to the more important issues first (getting the elements to react to touch events rather than the mouse, making lists scroll by clicking and dragging, etc) and then I’ll dive into some of the more specific issues. I’ll try not to keep you waiting too much longer, although there’s some work I want to get done in the next week or so, so I might not get around to it for a few days.

Regarding text elements (and other such elements) that need to continuously update, I usually override their Render methods in a way that fetches the updated values before drawing, like:

element.inherited_render = element.Render;
element.Render = method(element, function(args...) {
    self.text = "Updated text value";

although that may not be the most element solution if you need to do it in a lot of places - so I might at some point add some extra code to account for that sort of thing.

Okay, wow, that’s in-depth. Glad you seem to like it!

I don’t have the mobile exports so I can’t test it (currently), are there any other changes that need to be made for it to work smoothly besides the window mouse functions and the on-screen keyboard? It may be worth me making a configuration specifically for mobile. Performance-wise it might also help to optionally use the built-in GameMaker text renderer instead of Scribble - Scribble is great on desktop, but the text shader is a bit beefy so it may not be worth it on mobile devices, or laptops with integrated GPUs - as you seem to be seeing.

Drop-down elements might be a good idea (I assume you mean something like these), I might add one next time I get around to implementing new features. Functionally they’d be pretty similar to single-selection lists, except that they’d be collapsible when not active. (The original UI code I wrote that this is based on actually had something like that, but I didn’t think it worked very well so I didn’t include it in here - probably worth redoing at some point.)

I’ve also been (slowly) trying to remove the amount of hard-coding, but as I see you’ve noticed there’s still quite a lot of it left. Adding anchor points and other support for scaling is also something I’ve thought about - I haven’t needed it myself so it’s kind of taken a back seat, but a few people have expressed interest in that sort of thing so I should probably work something out one of these days.

There’s a compatibility script for the old GameMaker models, depending on how far you want to go with that (.d3d is a pretty obscure format).

Good fun! Not sure if you’re still maintaining this or not, but somewhere along the line GMS2 changed the way depth works, causing the skybox to get drawn over half of the screen. (It looks like someone else had a similar problem, but I don’t know if it was caused by the same issue or not).

Anyway, when you draw the skybox, you now need to force the depth buffer off (gpu_set_zwriteenable, as well as gpu_set_ztestenable if you really want) to prevent the background from persisting in 3D space after it’s been drawn. Not sure when GameMaker changed this, since it works just fine in GMS1. ¯_(ツ)_/¯

Also, I’m impressed that you managed to model everything in the game using exclusively paths. I would have just gone straight to 3D object files, lol.

Buckle up, everyone. (Get it? ‘cause it’s a driving game?)

The glowing singularity thingy that shows up at crossroads is a bit confusing, since for the most part you’re supposed to move towards the glowing things, while the singularity thingy hurts you.

Otherwise, good job!

Generally speaking, it’s the direction opposite the vector of gravity.

Okay, I didn’t realize that the design changed - but now that I look closer at my Xbone controller I see that’s what they are now. Good to know, thank you!