RGEE Update #1

RGEE uses image waveforms.
They can really eat up your graphics card texture size limit. So to work around this, i made it so when the width exceeds the limit, it just put the excess right below!

(Something like this)

When i was redoing the waveform generation code, i realized it would't work forever. So now, when it exceeds the texture limit height, it will then just squash it vertically. Retaining time accuracy without much visual loss!

1024x1024 texture for a 2-minute song still looks pretty good!

I don't think a 512x512 graphics card would even get to this point, but you can at least still make out the beats!

There is probably a better system that could be done, but i'm just particularly fond of this!

RGE Engine Story

I figure i might as well start blogging about my projects. I've done so much and plan to do so much that it's probably no good to keep it all secret.
Today i'll share my story on RGE Engine, a rhythm heaven-style game/engine with an editor. You can find it's current progress here: Github Link

This is a project of mine that has been going on for quite a while, and it has many predecessors. One of which is Custom Karate Man, which you can find on my youtube channel!

The Custom Karate Man engine was just programmed for karate man, there was no room for different types of games.

After i got tired of Custom Karate Man, I would try to make a good framework for more rhythm heaven games. First attempt ("Rhythm") was simply a more modular code base, i then realized that wasn't the most clean solution. Second attempt, i tried and succeed at making a new lua sandbox enviroment, in which i started work on cloning Cheer Readers alongside RGEE ("Rhythm 2").

Through both of my attempts, i also added Waveforms, made a neater "Node" system which does not rely on a single-level array, and made a beat-finder that makes it dead easy to add new songs.


That leads us to the RGE Engine, i've been working on and off. And it was always sort of planned to be released eventually but i never shared much about it.

But now, i've been re-inspired to work on it again, and progress is good! That's where i am today.

I would love your feedback and any future rhythm game makers to come check it out! (Still in the middle of revitalizing it though.)

My Mac Thoughts

I love Macs, i really do.
Apple was a big part of my childhood. These amazing devices were extremely well made, and could do anything you wanted them to do! I'd play with the amazing software it shipped with or play a bunch of the free computer games at the time.

When i got my own macbook, i would end up doing tons of things with it. At first, i was pretty big into Minecraft, and i would play on servers, and even run my own! I installed mods frequently, and even made some recordings with the built in QuickTime Player!

Later on, Snow Leopard would lose a lot of support, which is frankly kinda sad. Snow leopard was pretty lean, and it had all the features you would always end up using. When i had to move on to Mavericks, i would just change things to the way they were in snow leopard. I would change the finder sidebar to the same layout it had by default (Who could find "All Files" useful?). I would remove the notifications bar, as it was taking up space compared to the much more useful spotlight tool. And i would remove launchpad from the dock.

It was pretty clear OS X was changing, it became more bloated with redundant features, while also becoming much more restrictive and losing support for a lot of features and formats that would still be pretty useful today (Native Midi support for example).

It's not all too bad, as a lot of the phenomenal design of OS X still exists in mac OS today. But apple continues, changing the software around for the worse in my opinion. It's a good thing theres tons of amazing third-party software out there for mac.

These are just many of my nitpicks. Macs are still pretty amazing, but just aren't as great as they used to be, in my opinion.

How small can you store Pokemon EVs?

How many permutations can Pokemon EVs have, and how small can you store them?
There are 6 stats (hp, atk, spatk, def, spdef, spe), each of which have the range of 0-252

There is a maximum of 510 points to be used for all the stats, so that would dramatically lower the amount of permutations.

If we didn't have this limit, it would be easy to figure out how many permutations EVs would make.
253^6 or 253x253x253x253x253x253
Which would be: 262254607552729

I had no idea how i could calculate in the strange limit of 510 points, and couldn't really find much answers.
So i instead just brute forced it and got: 10362121
That's a dramatic difference, and would definitely well translate to storage.

I find that it fits within 3 bytes.
24-bits or 3 bytes = 16777216
That means we save three bytes compared to how EVs are regularly stored, which is 6 bytes for each stat.

Loading it now becomes another problem. The data is now numbered by what permutation it is and you can no longer find out what stat spread you have without some brute force matching.

We could use a look-up table that stores each combination.

10362121*6
(number of indexes) * (the 6 bytes for each stat)
Which is:
62172726 bytes
60715.5 kilobytes
59.2 megabytes

(Not even counting pointers!)

Needless to say, the trade-off is probably not worth it.