I copied the code you gave into the file, ran convhex, and transferred the appvar. I then edited the Read program above so that it read 3 bytes (the same size convhex said that the appvar was), ran it on CEmu, and it displayed "16"!

Just to make certain, is the code I have in the Read program the correct/best way to read an integer from an appvar?

If this is your code, then probably it will be okay for now. Otherwise you could try out some pointer shenanigans, but it's probably not worth it:


Code:

I am having trouble reading both integers and strings from the same appvar.

This is the code I am using to read the data out of OmicronC.8xv:


Code:


And this is what Clues.bin (the file convhex takes) looks like in hex:


Code:


Which is supposed to be: 16Move all pins up

When I run the program in CEmu, '16' appears in the upper left-hand corner and then the program prints garbage until the virtual calculator crashes.

Could someone please help me?

I usually use this sort of thing when I read integers out of appvars:

Code:

I'd try that instead. ^^o is SC3 notation for the degree sign.

The issue with your code is probably because you have to convert from hex, which you can do with the little uppercase E thing.

EDIT- So like E{VARIABLE}->VARI
EDIT 2- Try EVARIABLE->VARI instead, you've already read that out, right?

Here is the code I used for the last try:


Code:


It prints the same result but looks cleaner. Is this correct?

If CLUE isn't an integer, don't use the ^^o, read to Str1 or something else instead (without "^^o"). No need to use E either if you've read LENGTH out as an integer.

ICE question

How do you dereference the pointer that sub( command returns so you can store the substring to an OS string variable?

Progress Update

The Lock Picking puzzle now has all the clues for each level as well as the proper lock solutions for each one. I am hoping to get this puzzle finished in the next day or two, so I can work on getting the Shop and Main Menu finished. Once that is complete, I'll start work on the next puzzle: Computer Hacking.

In the next puzzle, you have to extract data from a computer while keeping a watchful eye out for a lurking anti-spyware scanner that will sound an alarm if it detects any suspicious activity.

That computer hacking puzzle sounds interesting... good luck!

Copy the data you want into a buffer.
The OS strings are already pre-allocated in ICE. The compiler detects the ones you use, and allocates space for each of them in the order they are used iirc.

Code:

And use the OS strings as buffers.
Hope this helps!

Thanks, beckadam, that helped!

However, I have run up against another problem that I am not sure how to solve. When I print a clue, solve the lock, and print the next clue, the previous clue is not erased. The next clue just draws over it, and whatever it does not cover of the previous clue appears.

My first idea was to draw a white rectangle over it between clue printing. This would, in theory, erase the previous clue, leaving a clean slate for the next. In practice, no. It appears that when the text data is written to the screen and a graphics command draws something over it, the text data is somehow remembered by the calculator. The next invocation of the SetTextFGColor( and SetTextBGColor( for the next clue makes the old clue magically reappear.

Next, I tried copying the screen to the buffer, repeating what I did above, and SwapDraw-ing. This would, I thought, force the calculator to forget the old clue data. In practice, no.

Lastly, I tried invoking the SetTextFGColor( and SetTextBGColor( before drawing the white rectangle, thinking that the old clue text would display to be instantly covered by the rectangle. In practice,... ...no.

I hate to keep on pestering everyone with questions, but this problem has nearly floored me. What do you suggest?

Try always drawing to the back buffer.
use det(5,color to erase the current screen/buffer
and only use det(10 or det(11,1 when you want to show the screen

I made a test program drawing only to the back buffer and clearing the back buffer after each SwapDraw, and it's working! Thank you! Now I can figure out how to alter the puzzle program to do the same.

Edit: Unfortunately, I could not alter the main program to get this trick to work. However, I was able to approach the problem a different way and so far, it seems to be working. Now the clue and codebook are on one screen while the lock is on the other screen, so I can erase the codebook screen and redraw it without interfering with the lock picture. It will require the player to remember the solution after he decodes the clue which will make the puzzle even more challenging.

And I also have another...

ICE question

How do you put the bytes for '1000' into an appvar?

The hexadecimal for '1000' according to Wikipedia is '3E8'. However, I don't know how to convert that into 12 bytes for ICE's requirements.

Edit 2: I found another way to put '1000' into an appvar: reading out one integer at a time four times to build a 4-digit number.

In ICE, you would just write 0003E8, which is the 3-byte value for 1000. You could also store 1000 into a variable, and then write 3 bytes to the appvar from the location of that variable.

Why do you need to store 1000 in an appvar?

It is the offset placeholder. For each round of the Lock Picking puzzle, the player needs to solve the lock three times, each with a different clue. After the player finishes one round, the program saves the current offset of the clue appvar (OmicronC) in the same appvar. The reason for this is that I close OmicronC when the puzzle program exits to avoid any chance slot complications (this might not be necessary, but I am not wanting to take any risks) and closing the appvar automatically resets the offset. So, when the player finishes one level and comes back to the Lock Picking puzzle again in the next level, the program reads out the saved offset and then knows where to go for the next three clues.

Thanks for the response! That will definitely be more optimized than what I have currently.

Edit: Unfortunately, the hexcode isn't working out for me. If I put 0003E8 in appvar using convhex, the read program returns a number bigger than 15 million. Also, if I write 1000 to an appvar with Write(, it stores C34462 to the appvar which the Read( command returns as more than 62 million. Do you know what might be causing this?

The ez80 is a little-endian processor. You should store the value E80300, as bytes are read from lowest to highest from left to right.

Progress Update

The Lock Picking puzzle is now complete and integrated with the main program!



It's a little hard to follow what keys I am pressing to access the menus, so here is the general guideline that I used for making the navigation:

Arrow keys: Move selection cursors, lock tumblers, etc.
[2nd] and [enter]: The 'click' function (the challenge menu help also gives [y=] and [graph] for on-screen buttons)
[clear]: Return to previous menu or exit puzzle

I am considering making the buttons flash when you 'click' on them to make the navigation a little bit more intuitive, but that will probably be postponed until I get the Shop and the next puzzle done.


What is left to do:

1. Finish the shop UI
2. Put the mechanics behind it (upgrade variables, resetting, etc.)
3. Connect the codebook to the Shop for upgrading
4. Implement the Computer Hacking puzzle and connect it to the Shop

I am hoping to get both the Shop and the Computer Hacking puzzle completed this week, so it will be ready for submission. The game will not, unfortunately, be as complete as I had previously hoped for the contest, but I will definitely give my best shot at getting as much done as possible in the next few days.

Edit: Yes, the thread number in the About menu is wrong. I was just guessing because I didn't know the actual number at the time.

The latest screenshot looks very polished, nice one! .

Wow. I just took a look at the latest screenshot, and it looks incredible. This will almost definitely be a contender for the win in my opinion, considering just how much stuff is in the game (puzzles, well-thought-out menus, help for the player) and how polished it all is. Good luck! I can't wait to play this game for myself.

The computer hacking puzzle does seem a little bit random, though. Is there any skill involved in it, or is it all just luck?

Thank you for the feedback! I'm sure that your game will also be a very strong competitor.

The scanner in the computer hacking puzzle is random - with a few modifications to make sure it always picks different files each time it makes a fresh selection and leaves at least one file unscanned if the number of files remaining is less than or equal to the number of scanners.

Just wondering; I played this recently and got to Week 10. Is this game no longer receiving updates, or are you gonna update it? If so, I will be very excited!!!