Ah, fair enough, glad that you see it as well. What are you going to change that will fix this?

Right now, I just delete the tile in the appropriate place, and hope the inertia of the craft is fast enough to overwrite the tile.
In the future, I'll take over the main loop and do this manually. This is also how I'll add the drill animation.

Very nice usage of grayscale, SirCmpwn! It looks great.

And will that make the apparent speed faster? I assume that that must be the case.

Right. I'll normalize the speed between the two.

Thanks!

Ah, that makes perfect sense, thanks for clarifying that. Do you have any estimated schedule for the completion of this? And how about tiDE and KnightOS?

KnightOS and tiDE are suspended (although there is supposedly more people working on tiDE, though I rarely see evidence of it) until I'm no longer grounded.
Motherload will probably be done in a few weeks.

Sorry, no demo today. It's never guaranteed that I'll be able to get to a TI-Connect capable computer while grounded, so I'm afraid I don't have new screenies or a new demo. Friday is probably the day to get a new demo.
However, I'm growing increasingly more concerned about this project. Today, I added some basic drilling animations for one direction, which took up about 1,000 bytes. However, I currently have 3,000 bytes worth of space remaining in the app to fill with stuff, and two more drilling directions would sit me at 1,000 bytes remaining. The surface buildings will probably take up 2,000 bytes in images and code, and the main menu will probably take up about 2,000 bytes in images and code, so I had to take out the drilling animation. That leaves me with very little wiggle room to add more features, unfortunately. Plus, Motherload is pretty darn optimized. I also only have about 100 bytes of RAM available, which I need to use for storing cargo, as well as information about how the user has upgraded their craft. I'll need to find some corners and cut them, but hopefully I'll be able to crank this out with a reasonable feature set.

Any ETA on either of those, or there's really no possible way to know?

Sorry to hear that you're struggling with space. Multiply that by ten or a hundred, and you'll understand what I go through when I need to cram things like Direct USB gCn into Doors CS. Best of luck.

No way to know, I'm afraid.


I can imagine, but at least you can span multiple pages I'm limited to ~16,000 bytes.

Not really; I have to keep related systems on the same page to maximize speed. I have some leeway to move code between pages, but it has to move in full blocks of related functions, so I don't often do that. Anyway, best of luck working this out; it sounds like there are quite a few Cemetechians looking forward to it.

Have you asked Weregoose? He might have some good ideas on super-optomizing, not saying that yours isnt already optomized. Just maybe he might find another way?

Love the screenshots! I can't wait to have Motherload on my calculator! Stick Arena Next! XD

I see, KermMartian, thanks for clarifying.
0rac343, as far as I know, Weregoose doesn't know Axe.
Also, I've been able to optimize away 1,000 bytes, so I'll keep optimizing and hopefully be able to get more out of it.

Oh yeah, I was going to say the same thing. Weregoose is a BASIC expert, but I don't think he's familiar with Axe or ASM. SirCmpwn, is the problem that Axe compiles inefficiently, or just that it's a lot of stuff that you're trying to do?

The problem is both. Axe presents the same problems you get with any other high level language, and I'm trying to do a lot of stuff.

Also, new demo! This version fixes the bug where you could only go down to about 100 feet. A new bug sets the current limit at 342 (you can go further, but the map is corrupted and I'm not responsible if your calculator eats your babies). This one also has damage implemented, so try not to hit the ground too hard. The GUI is also being fed live data every 8 frames, though if your hull reaches zero or your fuel runs out, nothing happens. Also note the increased speed when scrolling down, with the new optimized method for doing so.



(Download)

How is feet calculated? Five feet per block, ten feet per block? Or One Block = One Foot?

I mean to say meters, where one tile = 1 meter.

That makes sense. At any rate, any progress on this project, SirCmpwn?

Right now, I'm just optimizing. So far I've squeezed almost 2,000 bytes out of it.

Nice job! What's the primary thrust of optimization at this point? Pure command optimization? Code reuse? Insertion of inline ASM?