adamantyr
-
Content Count
1,852 -
Joined
-
Last visited
Posts posted by adamantyr
-
-
Well the block in the wall only happened when the door was there. I tried to do it next to a wall. So that is not real important. The portal lock is bad. Cause u have to break the program and restart.
Speaking of restart are you going to have a level skip or password to another level. Be nice if when I play again and I'm on level 7 or whatever that I don't have to play from the beginning.
Only when the door is there, interesting... would like to at least identify the cause there.
I'll have to look over the check code again for the portal fall-through... I had it so it kept moving you 2 over if you shifted at all, because it treated it like you were falling off an edge. I didn't like that, so I worked to get it to only move you one square. Hopefully there's a simple way to restore the move-away to break out of a portal loop.
I hadn't planned on a level skip. The game doesn't end at any point, or regress you to a prior level. Plus it scores how many times you restart or die, so a level skip would break that.
Still, if you want to start at a different level, just change line 770 to L=# to set it to start at a different level.
Adamantyr
-
Hm, the "push block on any axis" code is relatively new, not surprising you managed to find a bug. It's supposed to only move the block into an empty space, though, weird...
I think I know why the portal skip-out is no longer working... Blast it. I had to make other changes so that falling out of a portal let you shift one space to left or right, which necessitated other changes... one of them is applying a Y-axis value on you when you attempt to move out of the portal. So you hit a block diagonally and are stopped, thus, you fall back through.
Any complex system has a number of edge cases. I know of a few in the game that I can live with; BASIC just doesn't have the memory or speed to cover every potential case, and the ones I've seen were mostly harmless.
Adamantyr
-
On vacation, can't work on my game for a few days, I DL this and let my son play who has beat Portal and he liked this game. a couple of things we noticed that may be fixed. I think the first was mentioned, 2 portals on the ground walk into one and a endless loop starts that you can'r ® out of have to F4 it. Then on level 4 got the box top of the do even though it's a wall spot. Going to play it some more! Really enjoy it!
Glad to hear it. Hm, can you post a screenshot of the second problem? Also, I know if you put two portals straight down, you should be able to move away... are you pushing a cube through first?
Adamantyr
-
Those cartridges modify the console BASIC in GROM to allow for extra calls, but to my knowledge--- they're written in GPL.
I could break out of Hyper Racer, which is a cartridge-based BASIC launch. So yeah, other than cutting the pre-load, it operates like any other BASIC game.
Adamantyr
-
Yea, only the arithmetic jumps should be used if negative values are a factor. Otherwise, unsigned values invert the number line; -1 is highest positive value, so it messes comparisons up.
If I may ask, what exactly are you doing that requires negative values? In my own experience, there isn't a lot that mandates their use that can't be reworked into a base address + positive offset, which is generally easier to work with.
Adamantyr
-
No feedback yet? Only one download?
Adamantyr
-
Sorry for the late post... Blizzard WOULD choose today of all days to update the World of Warcraft with all the earth-shattering changes to the zones, so I just had to check it out...
Anyway, I've got all sixteen levels encoded into the game, and was working through play-testing each one to make sure they're solvable, and also catch any last-minute bugs and errors from transcribing them from paper.
However, I've run out of time as I need to get ready for a trip over the mountain pass for Thanksgiving tomorrow. (With lots of ice. And teen degree weather. Yay.) So, having tested at least 12 of them, I'll throw the rest to you guys to find the bugs.
Note that the game takes up nearly all the memory BASIC has to offer. There's no way this one can be run on iron without (ugh) typing it in by hand. Fortunately, there's an easier solution: offload all the level data to disk. That should cut it down enough to fit easily in BASIC with room for a disk controller. I'll probably do that for completeness sake.
Adamantyr
-
I may have found an endless loop, if you put portals on the floor in two places and shove a box in and then walk in yourself you alternate you,box,you,box and it seems to ignore keys..
Yeah, you don't need to push the cube in first.
I did fix that, although maybe not in this particular code package...Try pushing hard to the left or right right after coming out of the portal and you should be able to get out of it. (I made sure it loops back to check for a joystick movement BEFORE checking for gravity, which naturally would drop you back in.)
Full game will be coming soon. I have to finish encoding the levels (which takes FOREVER...), make sure they're all winnable. I will also put together a disk-based version that loads the levels from disk, which would shrink it enough to work in BASIC with a disk drive.
Adamantyr
-
Here's a question...
Does anyone see any value in a multi-player turn-based game in BASIC? In the old days, it was nothing unusual; you kind of played with your siblings and just turned your back while they took their turn. (Well, PRETENDED to, anyway.)
BASIC really only has enough memory for either a 1-player game with an AI, or 2+ real players with no AI. What do we think is "good" for the contest? Stick to 1-player games?
Adamantyr
-
when you swap to it, do you just redefine the Screen Table and it redraws the screen based on what is stored in the new addresses?
Exactly. It's a zero-sum transition because on every VDP cycle, it's just reading that register and writing to the screen whatever it finds there.
Adamantyr
-
Hey Adam you have screen table and buffer screen table, so are you double buffering your screen output?
Yes, I have several cases where it just rebuilds the entire screen in a buffer and then swaps to it. That lets me update the screen without any rips, tears, or corrections needed.
Classic example: You have a number value that has multiple significant digits. The value drops from a four-digit value to three. but unless you are adding trailing spaces to your string output, it will not wipe out the fourth digit and you have a misrepresented value.
Adamantyr
-
Okay... I've drawn up all my test chambers, and the final "computer core". There are 16 levels in total. So far I've got ten encoded into the game, with about 2048 bytes left, so I should have enough. This will definitely be "too big" for anything except cassette.
Encoding is a pain. It takes me a half-hour to do one level, and I often make adjustments if my original map was a bit too ambitious for the HCHAR/VCHAR system to set up effectively. Still, it takes way less space than printing them. I'm using an Excel spreadsheet to help the process, but still a lot of exacting work. The fact I have to go in and manually enter the control characters into the strings takes time too.
Also, I may have gotten a little sadistic in some of the levels... serious joystick skills are needed to finish each level. And yes, you are being scored.
Look for my post to the thread tomorrow evening, hopefully.
Adamantyr
-
Awesome!
Incidentally, BASIC is much more difficult to make games that work well in overdrive mode. In Extended BASIC, I could through in a PEEK to the interrupt timer to slow things down in a way that overdrive respected, but that's not possible in BASIC.
So you should go whole hog and either make your game absolutely require overdrive, or playable without it.
Also, Owen, we should start up a submission thread for the contest? I just got 10 levels to encode and a little testing to do and the complete Aperture should be ready.
Adamantyr
-
When the game contests started up around here again I was thinking of making an entry, but then remembered all the reasons I dislike BASIC and XB (besides how slow they are.) No indentation, no labels, comments that eat up memory, etc. I've wanted to make a new language for our beloved 99/4A for a long time, but alas that is just another project out of many on the list.
However, in lieu of a new language, I figured it would be easy enough to add some of those features via a "translator". You would still code with BASIC, but without line numbers and such, then the translator would trim out spaces and remarks, add the line numbers, and spit out the code to copy and paste into Classic99.
I wrote the guts of it last night with these features:
* No line numbers allowed, they will be assigned
* Labels can consist of A-Z, a-z, 0-9, _, and -. They can be any length, but a maximum line length is 256 characters. Label "definitions" must start a line and end with a single colon. Labels can be referenced any place a line number can be used, currently: THEN, ELSE, [ON]GOTO, [ON]GOSUB, and ON ERROR.
* Comments are stripped from the code. Comments are any line that start with REM or // (C/C++ style single line comment notation). XB also has a "trailing comment" designated by a ! that causes the rest of the line to be ignored. These comments will be stripped as well.
* Leading space is ignored so you can indent as much as you like.
* Long lines can be split by ending a line with ... These lines will be joined into one long line and the XB limit of 140 characters will be checked.
* Starting line numbers and the increment can be set.
* A keyword "proc" can be added to specify "procedure" line numbering, which causes the line number counter to change to the next highest multiple of the specified value. What this does is allows you to number subroutines starting at certain values, like 1000, 2000, 3000, etc.
Features I was thinking of adding:
* Support multiple source files.
Currently the translator is written in PHP, which makes it conducive to being set up on a webpage. However, that might make development cumbersome, so I was thinking of making it a native Windows app. I'd like to hear opinions either way.
Examples coming soon.
Matthew
A command-line app would be fine, although a native Windows app would be cool too. You could whip something like that up in C# easily enough.
Looking forward to seeing it! Line numbers are a pain, indeed, to deal with.
Adamantyr
-
Latest version... six chambers now available! Also, if you get stuck, press 'R' to restart the level.
Added some new stuff on test chamber 6, so be sure and try it out!
And yes, I'm aware that cubes can destroy ladders. I don't want to waste an array tracking what's behind cubes. Just be careful.
Adamantyr
-
Err - Guess I'm an idiot, but with Classic99, it's pretty unusable... My issue was I started Classic99 directly (w/o it knowing where it's installed) so that it just ignored speech. Using it with XB is fine, but TE 2 is not really understandable. Gotta try MESS.
I think I tested this in MESS once, and it's a little garbled there too... the problem being that none of the current emulators have the EXACT speech core that is in the TI speech synthesizer.
I thought about using the cartridge for Aperture, so I could have the main computer taunt you after each level, but I'd have to go back to original iron for testing, and all those speech lines would eat up memory I could use for interesting test chambers.
TI-Trek has TE2 speech, and you usually just ended up going without after the novelty wore off.
Adamantyr
-
I'm a moron
Don't feel bad, I did the same thing myself. I was in Super Extended BASIC re-sequencing the line numbers and I forgot.
I really need to get my Extended BASIC III cartridge over to emulation... it's a tough one because it's a complicated cartridge with four 8k pages to retrieve, but XB3 will support loading and running BASIC programs. (It no longer throws "bad value" if you use characters above 143, but you also can't use sprites.)
Adamantyr
-
(Double-post, AtariAge is really acting up at the moment)
Adamantyr
-
Latest version now available! Five test chambers available to play, numerous refinements to controls to allow for a lot of variety in desperate moves. Also added a title screen.
I think I have most of the main features coded up... not all of them have actually been tested, but it's just fixes and refinements now.
So far, I've used up around 9.5 kilobytes. That leaves a practical 3k or so left for the rest of the test chambers and any code additions. I may go back and refine some of the test chambers or even replace them to make room for more challenging and interesting chambers.
Please feel free to post any bugs or oddities you find here.
Adamantyr
P.S. Yes, Test Chamber 5 IS solvable... it's not easy, I'll admit, but it is.
-
1
-
-
I believe the reason why is this. When we use CALL GCHAR the computer reads 1 byte of VDP memory and stores it in a variable. Now since all variables in basic are floating point you might think this would be a double word operation but it's not, just a single byte.
Arrays on the other had are one sizes fits all. So they are all double word for floating point storage and therefore every access is copying 4 bytes of memory.
Anyway that is my reasoning for it.
Nice work! I thought I could use subprograms in Extended BASIC to do a little recursion but no such luck... the TI engineers specifically state that recursion is not supported. Bugger all.
One small correction, though. Floating point on the TI is 8 bytes, not 4. The reference guide certainly says that 13-14 significant digits is there, I imagine that they just don't show you the entire thing in BASIC.
BASIC may only be copying the most significant 4 bytes of the mantissa, though, I've never looked closely at the interpreter.
Adamantyr
-
I realized that basic doesn't support composite conditional statements... That sucked to remove.
This will be my last BASIC game EVER!
And - manual line renumbering is oh so much fun...
Yeah, I've had more than a few errors from retyping line numbers in the text editor and accidentally leaving a double in... which naturally Classic99 pasting just overwrites the first. :S
Super Extended BASIC has line number commands like MOVE, COPY, and selective range RES, but it's not available on Classic99. I got the MESS ROM's, wonder how easy it is to add them in...
FOLLOW-UP:
Yep, no problem! The program may not run in Extended BASIC, but I can certainly use the tools to save a little time on line re-numbering.
Adamantyr
-
Don't have a cow, guys!
Adamantyr
-
I made some changes to the character layout and was forced to redo what I had done. Probably a good thing because I have had the chance to go back early in the piece and address a few things I was not happy about, mainly the characters between 128-143 which were in DATA statements (between quotes), and did not paste from Ti99Dir into Classic99 properly. I have juggled the character sets and now it can paste into Classic99 with no problems. This now raises an interesting option before I go much further. What are the thoughts on if I should write this with the intention of it being run under Classic99 throttling, as to opposed to my original intention which was to have it run on standard hardware? ie- The difference is I start writing with CALL LOCATE instead of CALL MOTION. I am leaning towards Classic99 Throttling but know it will be completely unplayable on standard hardware (and this would have been nice). What are the community thoughts?
Here is the new Classic99 friendly code with the characters in set3 13 & 14 juggled and corrected. Paste away!
Well, two schools of thought here...
One, it is a crap game competition. So overshooting the platform's abilities so it runs terrible makes sense, because otherwise the game may be too fun... even with the general tastelessness.
On the other hand, there is the challenge of writing a good game that runs on the original platform.
Of course, you can always do two versions...
Adamantyr
-
And then it struck me. The method by which a dungeon is developed has "nothing to do with" displaying it!! Like Adam suggested earlier, I went back to my graph paper and REALLY started thinking about "why" I was drawing it the way I was.... THAT is the algorithm... What happens after that is really inconsequential to the maze itself. =) The maze algorithm exists and mazes are generated EVEN IF you never display them... This may not be "groundbreaking" to some of you, but for me it was a nice slap in the face.
Congratulations! Perceiving the difference between design and the code itself is an important step in any software development.
Adamantyr
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
TI BASIC Game: Aperture
in TI-99/4A Development
Posted
Working on fixes... unfortunately I ran out of memory trying to fix the portal trap issue, because I had to add extra code to check for movement.
I was trying to recycle existing code, the problem was that it ALWAYS displaced you 2 spaces if you went left or right from a portal while falling. I have several levels that would be unsolvable in this case.
So, the cool opening title sequence has been axed. Back to two print statements.
And yes, I SAID it would not work on a base console unless you used a cassette player.
This is truly a cassette-only TI BASIC game. I can make a disk version that loads the level data off disk, but that comes after I am certain all levels are playable and solvable and all major bugs are fixed.
Adamantyr