How does this sound?
 40%  [ 6 ]
Very good.
 46%  [ 7 ]
Good, but you're never going to finish.
 13%  [ 2 ]
I don't care.
 0%  [ 0 ]
 0%  [ 0 ]
 0%  [ 0 ]
Total Votes : 15

Argus wrote:
Definitely get the AI and collision working first, and then the ICE editor last, because you need a real game for the level editor. Also, this is sounding amazing! So much further than I am... I would love to see some screenshots if possible! Good luck on finishing in time!

No, I mean that the ICE editor is already basically done. I just did that during my free time when I didn't have access to a computer, so it didn't take up any C time. I'll post screenshots in a few minutes (you can see them in the latest screenshot section in the original post).
Ok, I just thought you hadn't finished the editor, but nice job!
Well, looks like it's about that time again.

I've had a lot going on recently, with no real end in sight, so that means that I don't have a whole lot of time to work on my entry in the near future. That means that there are a few possible outcomes for my CC23 future:
-the admins have mercy and give an extension, and I finish (probably)
-I have to rush the last bit of the game over the next week, and it's not as good as I originally planned
-I resort to a backup ICE or C program that I make at school (very quick, not too good)
-I try to finish, but can't

Just wanted to let you all know what the future may look like. I've had a lot of fun with this contest, learning C and some new programming tricks. Hopefully, I can finish, but there is a non-negligible chance that I won't. Good luck to matkeller19, bdoggamer, and beckadamtheinventor, who (I believe) are the only real people left in the contest (apologies if I missed someone else). Man, there's been a lot of dropouts this time around.

As I said before, I am going to try my best to finish, so don't think I'm going to let up. It's all decided by school and sports: they will either permit me to finish at this point or won't. Thanks for reading.

Cemetech Contest 22 flashbacks... remember good old DR0VE?
Can someone please explain to me what's wrong with my code?


void RenderMap(int level) {
    ti_var_t slota;
    ti_var_t slotb;
    slota = ti_Open("ACRCNMAP", "r");
    slotb = ti_Open("ACRCNSPR", "r");
    gfx_sprite_t *spr;
    uint8_t x;
    uint8_t y;
    uint24_t tile = 0;
    gfx_Rectangle(19, 19, 282, 202);
    if ((slota) && (slotb)) {
        for(y = 0; y < 9; ++y) {
            for(x = 0; x < 13; ++x) {
                ti_Seek(420 * level + (y * 14 + x) * 3, 0, slota);
                ti_Read(&tile, 3, 1, slota);
                ti_Seek(402 * tile, 0, slotb);
                spr = ti_GetDataPtr(slotb);
                gfx_Sprite(spr, x * 20 + 20, y * 20 + 20);
                MapData[x][y] = tile;
    } else {
        gfx_PrintStringXY("Error 01: Failed to open all appvars.", 5, 5);

Compiler errors (there's a lot of 'em):

Detected libraries to link: fileioc graphx keypadc

C CE SDK Version 7.5
Looking for changes...
./ACERECON.C   (73,19) :   ERROR (108) Identifier "gfx_sprite_t" is not a variable or enumeration constant name
./ACERECON.C   (73,23) :   ERROR (128) Identifier "spr" not defined within current scope
./ACERECON.C   (74,14) :   ERROR (100) Syntax error
./ACERECON.C   (75,14) :   ERROR (100) Syntax error
./ACERECON.C   (76,18) :   ERROR (100) Syntax error
./ACERECON.C   (76,19) :   WARNING (222) Statement has no effect
./ACERECON.C   (81,16) :   ERROR (128) Identifier "y" not defined within current scope
./ACERECON.C   (82,20) :   ERROR (128) Identifier "x" not defined within current scope
./ACERECON.C   (84,31) :   ERROR (128) Identifier "tile" not defined within current scope
./ACERECON.C   (88,32) :   ERROR (141) Object cannot be subscripted
make: *** [/toolchain/include/.makefile:256: obj/acerecon.obj] Error 255
There was a problem in the build process...

Thanks again for your help, everyone. Looking forward to (hopefully) getting this done for CC23.
I point you to the FAQ, which everyone should read:

Toolchain FAQ

When you get errors, it does not matter *how* many there are. All that matters is the first one. The first one tells you what the error is, the rest are just baggage.
Thanks, got map rendering working. Now, time to work on collision detection.

Edit- Well, that has to be one of the most productive 40 minutes Iíve ever had. Bugs fixed, map rendering works (with multiple levels, tiles, etc. being read from the appvar), player and bullet collision work. Hopefully Iíll have some more time to work later today.
That's pretty much how it works for me, I procrastinate for a few days, then grab my calc and get a massive load done. Anyway, good luck on finishing! I really want to see what this will evolve into Smile
So here's a screenshot. Please tell me what you think.

Not a whole lot of progress, considering this has taken a month, but I'm pretty happy with it. I still plan to finish before the deadline, we'll see how that turns out.
Good job so far! I like your graphics a lot!
Two problems I noticed: Occasionally when the black player was moving around, the design in the floor masked the direction line that shows which way they're facing. Perhaps you can make it a different color so it's easier to discern? I'd also suggest quickening the time it takes for each character to turn, it took the guard 16 seconds to turn around which is quite long and he'll probably miss you if you walk right behind him. Hopefully when you start optimizing you'll be able to speed it up a lot. If it's still too slow, I'd increase the amount of degrees each character can turn at once.

Again, well done and I look forward to future updates!
The black line wonít be a problem soon, itís just a debugging thing that will be replaced with a player sprite eventually. I will definitely look into the increased turning speed, however. Thanks for your feedback!

EDIT- Currently working on improved AI that will automatically turn around when it gets to a wall instead of moving between two preset points, which will increase speed by around 3x (I think) and be smaller/ more optimized, as well as decreasing the size of the levels appvar.
This is lookin' nice! I think you have a great shot at winning, probably the best out of all of us! I definitely think speeding up the guards' turning speed would be a great improvement. Or maybe adding a difficulty level that can alter their speed in settings :p
Anyway good luck!
I've got a new screenshot on the way that will show how the game can now handle two guards about 2x as fast as it did 1 before! So, about a 4x speed increase in the Renderguards(); function. This is done by instead of having two preset points, just having the guard turn around when it gets to a wall. It's a little bugged, but close to working. Also, the guards are now able to see the player when a) the player is not behind a wall and b) the guard is pointed in a certain angle relative to the player's position.

Edit- Screenshot:

Edit 2- Argus- thanks for your feedback! My top priority now is just finishing, then we'll see if I win or not.
Sorry for the double post, but I think this warrants another progress update. Guards can now shoot at the player, and the player can shoot back, potentially hitting and eliminating the guards. The player spawns in on the blue arrow. If the player can get to the green arrow without being shot, the level is passed. Also, the guards no longer need to see a wall to turn around, they automatically turn around when they reach the edges of the screen now.

Lots of progress today:
-guards are more intelligent, and can now aim to shoot at the player
-the game actually progresses through levels
-lives have been implemented
-main menu added, with the full about section completed
-general speed improvements and optimization
-the program checks to see if all of the appvars are available at the start, and notifies the user, then quits if they aren't

Here's a screenshot (worth noting that this is exactly the speed that a regular calc would run at):
Nice work Smile Turning looks a little slow; any way to improve that?
Looks great - is the collision detection only for 1 pixel in the middle of the character?

Also do you plan on having the bullets be reset on respawn?
tr1p1ea wrote:
Looks great - is the collision detection only for 1 pixel in the middle of the character?

Also do you plan on having the bullets be reset on respawn?

For bullets, collision detection is based on whether the bullet is within 4 pixels of the center of the player/guard. For walls, if the tile that the player is attempting to move onto is not a floor tile, the player canít move at all. Yes, that is measured from the center of the player. Would you like the leniency for that to be larger?

And yes, I plan on adding some code that will invalidate all bullets upon level completion/exit later today.

Thanks for your feedback!
I think for the comp just leave it at the centre of the player regarding walls etc.

If you add the bullet reset stuff will that mean you will be able to submit? Exciting!
So an update on progress: I completed all 20 levels for the main game and added a pre-level screen, as well as fixing the bullet bug that Tr1p1ea mentioned.

To do before submission:
-add enemies (specific for each level)
-integrate player and enemy sprites

After some thought, Iíve decided to leave out the statistics and options menus for now so that I can focus on getting the main gameplay as polished as I can. Weíll call this a beta release, I guess. Donít worry, I promise to update the game at some point.
20 levels and that awesome new turning speed!? It's looking amazing. I can't wait to see the sprites in. It's gonna look so neat! Btw if you want help with map design, I could help you. I may not be much of a sprite designer, but I love to design game maps!
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 3
» All times are GMT - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum