Yes, yes, I get it. I failed. So hard that you’ve found the need to invent new words to describe it! I am an intense disappointment and I apologize for creating this depressing vortex of not-making-games suck.

I’ve been a horrible combination of busy and lazy. School work and stuff keeps me bogged down, and then my friends keep wanting to do things. Help me ruin my life so I can have free time to make games again! Much appreciated.

At any rate, a small return to progress is being made. I’ve discovered a few bugs with the LuaVerge v3 namespace I wrote, through further development. Support for joystick wrapping has been added. In the signal namespace, I created a “multijoystick” that polls all joysticks connected at once and treats them as a single joystick, and a button wrapper that allows an game action to be associated with both a keyboard and joystick binding simultaniously.

I added a really cheap placeholder beacon transmitter entity type, which is used to calculate the player’s signal strength when the beacon is on-map. Here’s a picture of this in action, not exciting looking at all really, I can assure you:

Get it here, but don’t expect to be amazed in even the slightest way, unless you want to try out the relatively non-exciting joystick input crap or something!

Anyway, back to talking about the beacon entity stuff, I quickly saw they had huge overhead when I was getting about 30fps with only ten signal beacons placed. It turns out the big bottleneck was caused by accessing entity properties from the v3 wrapper. Each reference to self.ent.hotspot_width and self.ent.hotspot_height hurt the performance drastically, because of the amount of magic lookups being done, both v3-namespace side and raw LuaVerge-side.

LuaVerge wraps entities in nested lookup tables that transform all that crap into a native C++ function call, one table being the index, another being the entity’s property (like hotw and hoth). Let’s not forget the global table entry for “entity”, either. On top of these things, I insert even more overhead by creating classes with properties through Lua-side. hot_height is a property that contains a _get(self) function, which returns entity.hoth[self.index]. All the table searching stacks up! So I got around this by storing the hot_height and hot_width locally in signal’s entity extension, which is reasonable considering these things won’t change once the entity is created (unless ChangeCHR() is called). Uhm, there’s some refactoring that needs to be done at any rate. I will hopefully be able to cut the slowdown for most of the read-only entity variables. Things like entity x/y, will still incur an overhead because they need to be writable.

Anyway, there’s my progress and stuff. That wasn’t very exciting was it? See you again soon. I am announcing my return to Gruedorf, and escape from shameville.

Next time, I hope to maybe get all the art drawn so-far actually in game. Then I’ll worry about animating and fixing it all. (Oh by the way, that 255 entity limit in Verge? It’s just silly. I really want to remove that.)

This site really needs a facelift, too. The temporary copypasta mash together until it works and then go back and make it somewhat presentable yet still ugly and apalling and I really could have just made a nicer layout of my own from scratch if I wasn’t too damned lazy in the first place template thing just isn’t doing it for me, and I also want to tie in some non-blog areas to the site, so if in the highly unlikely event I have a lot of free time and I’m feeling adventurous and creative, I might fix it.

Now I need to depart, it is time for me to complete a homework assignment that’s due at 11:55 pm today. Thanks for reading words and stuff!

RSS feed for comments on this post. TrackBack URI