not taht a huge influx of axe users would be a problem...

The program isn't freaking out, it's just doing what you're telling it to do

Basically, you're telling it to display the string located at address 0x05. The problem is, the Disp routine displays everything until it reads a Null character, which is probably not close to the start of the string. You're passing it a pointer to an essentially random non-null terminated string. See why that might cause "unexpected" results?

Anyway, to try to put a stop to the thread hijacking, Ashbad: how's your program going? Are you making progress at a decent rate to fiunish it in time for the contest deadline?

I'll definitely finish it it time, but I'm now writing it on my computer for quicker development since playing ROL3 drained my batteries pretty quick

Lol. Good luck!

And don't forget to submit pix and videos!

I was working on this during my break in lifeguarding today, and I finished level loading and editing. I think I did pretty beast on my level compression techniques:

- there are many types of tiles in this game, and using byte indices would make the tilemap take up 180 bytes. I made it compress to one bit per tile, using the state of the surrounding tiles to determine the current tile type. Tha cuts it down to 22 bytes and an extra nibble, which I use to determine the "level" the current room is part of, which can determine changes in tile prediction as well. I then run it through a limited 2DRLE co oression algorithm that uses 6 bits to determine length, 1 bit for direction and 1 bit for state. It check beforehand to see if L2DRLE compression is nessicary or not, and stores compression state right after the beginning level determining nibble. One detailed room I made was only 12 bytes in tile data total, as opposed to 180.

- Enemies, objects, etc. Take up about 80 bytes per room. However, i made it so each unused slot starts data with a reset bit, which means to skip that bit and continue struct processing with a +1/8 offset and move to the next slot position. A room with two boxes only uses 10 bytes and 3 licks (half nibbles) of data as opposed to 80 wasted bytes.

- Since the sizes of rooms vary so much, instead of holding all rooms in arrays of 260 byte structs, each level-room array and data-level array is begun with with a static vector table for quick reference to rooms. The data-level array is an array of level-room arrays, and has an embedded and extended vector table after the heading VT that combines all elements of held arrays, and indices.

- A non-compressed level-room array is 5200 bytes. Compressed ones are now at the very most 2160 bytes, but I'm sure the actual output will be closer to under 1000 bytes. 1000 bytes for an action packed hour level is pretty a good

Well done Ashbad! I'm impressed!

I'll say that under 1000 bytes is a great level size. Can we see some screenshots of sample levels static or in action? Also, unless I missed where you said it in your post, how virtually large are these 5.2KB -> <1KB levels?

I would show screenies, but for now I'm still working on making the actual tile graphics for the predicted tiles placement though, if I get far enough along today, sure

About the size virtually (of a level), it would be consisting of 25 18x10 rooms each, which is about the same as a 50x90 tilemap per level size-wise (about the same as many original metroid levels, more specifically very near the size of Ridley's lair) which is a pretty hefty size. Each room would be about from 1 to 3 minutes to complete, since each room requires you to kill all enemies and finish a possible challenge to move along. That's about maybe an hour per level, which is very very very good IMHO for 1KB.

I plan on having at least 10 levels included with the opening game, to fulfill a storyline -- though I'll make it so after the competition I can make "content packs" that might include at most 10 levels each and have limited storytelling engines built in. I'm trying to soupe up my editor to be able to handle all of the shit I've been feeding this mushroom of a game

Well, I still can't show screenies ATM, but I can show mockups! Mockups as in one. All that I have done lately is shown here, and it looks 100% like that in game (besides the "Level 1-5" thing, I have two custom text routines, one for the "BULLET" and the other for "Level 1-5" I'm working on but it'll look like that):



I have enemy movement almost down (they can move, they have a line of sight and such, but I still need to get them to attack Drake and doze off after a while of you hiding). Then the enemies will be perfect state machines and will be awesome and kill you (in this replica mock, it shows only skeletons, which are one of the ~10 different enemies, which, as you can't see as the main character isn't included, are twice your size)

I also have compression working perfectly now, that above screenie looks like this with no prediction and only bits to map with:



This is compressed to about 15 bytes with my algorithm. The moon in the background is overlain on top based on the level nibble's value, and it is checked to see if the space needed for drawing the moon is occupied, and draws as much of it as possible.

HUD is now somewhat functional. Added a bullet indicator and a health bar (I finally got dithering to work well with this in-program) and almost done the level thing you see there.

And on a side note, I think UCTI is the first game that features a non-normallic 1st/3rd party scripting language (I made a scripting language, TCPS, found here in the projects section) on a calculator that can be used to mod and make add-ons to the game (almost 100% functional and documented)

So, decent progress today and yesterday

That mockup looks bloody amazing. If you can get the game to look like that, wow.

I agree with leafiness0's statement. And the progress made in such a small amount of time is amazing! Post the link as soon as the final is uploaded. I want this game!

I also like the mockup, I just hope he can make it

You have such small faith! I for one think Ashbad can do it!

I think that he can, but the thing is that we've seen a lot of disappointment on the author and player ends in the past. We're always encouraging to people who we think can do it, but we reserve the heavy compliments for completed projects.

Agreed. However, possible real screen tomorrow -- just have a new bug with the enemy sight lines, and it'll take all day to reorganize all my code to make it more optimized and functional.

You think that was a heavy compliment?!? Just wait until I get my hands on the finished game!

Where can I find the link to the finished program?

An excellent question. Now that the contest deadline has (?) passed, will you upload it to the Cemetech Archives?