Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: MRide on August 15, 2010, 10:56:32 am
-
I'm modifying this to reflect what's really going on. :P
This a pure BASIC RPG. It is a work in progress, and the .zip file is just the skeleton of the game.
The game is intended to be a quality BASIC game with decent graphics, so speed might be a little slow, but that sacrifice means cool animations, graphics, etc.
Here are the features currently implemented:
-All maps, character movement, etc.
-Saving (at any location.)
-Information boxes that drop down.
-ability to pick up keys and gun.
-Character appearance change when gun is picked up.
-Title Screen
Working on:
-Battle System
Screenshots:
(http://img.removedfromgame.com/imgs/1282970296-IMAGQUEST3.gif)
The key puzzle
(http://img.removedfromgame.com/imgs/1283548494-IMAGQUESTKEY.gif)
Title Screen
(http://img.removedfromgame.com/imgs/1283606986-IMAGQUESTTTL2.gif)
-
Looks pretty nice!
If you want to experiment with some other cool layering techniques (especially for a battle engine), check out this topic (http://ourl.ca/6381). Or you could mess with offset text sprites, like the ones in Elmgon or Serenity.
-
Thanks. I haven't thought too much about the battle engine yet. I wanted to make sure everything worked and looked good first.
-
A quick graphics question:
Which one of these looks more like a key? This is meant to replace the Greek characters. (Thanks to Builderboy for his Java program.)
(http://img.removedfromgame.com/imgs/1281978389-keys.jpg)
These are the two best ones I could find.
-
I like the first one better :) Heh and your welcome for my java program, im glad its being put to good use :)
-
I like the first one as well. Yes, thanks Builderboy for that. It's a great program! ;D
* ZTrumpet tries game now. :)
Edit: Wonderful game! You've done a very nice job on this. I like how all the maps look. We need more RPG Dual-ASCII greatness like this. ;D
-
Thanks. I'll go with the first one then.
I'll upload the newest version in the first post when I get something significant accomplished.
I have a lot of reading to do the next few days, and school starts after that, but my Java teacher won't care if I work on this instead. O0
-
Also, is this called Imagination Quest? :D
-
Yes, how'd you guess? :P
The name refers to a surprise twist I have planned for the ending.
-
Ok, cool. Good luck! ;D
-
Wow nice graphics, nice usage of dual layer ascii sprites.
-
Very nice! This is really nice. What exactly are all the tokens that are disappearing when you go on them? How did you decide to store the characters for the maps? Also, what are you doing for collision? pxl-Test(?
As for the key I like the left one too. Also, just a possibility, since you are on the graphscreen you can always just put a Pxl-Off( after you display a key to take away a pixel to make it more key-ish.
-
You mean the Greek characters? They were just stand in until I found a good character (they are replaced by the key character in the update I just uploaded.)
I'm using strings to store the map data and collision.
-
Yes, how'd you guess? :P
The name refers to a surprise twist I have planned for the ending.
Sounds cool as long as it is better than the massive plot twist at the end of the DS version of Drawn to Life: The Next Chapter.
-
Sure, I don't think they were all Greek letters but I don't remember. But ah ok, I'll check it out.
As for the maps I meant what did you decide to do for them. Like storing then in separate strings or in the same string? Are they lined up in the strings or is the order reversed? Or what?
-
Two strings, and one is reversed (I think that was your suggestion)
The characters you can walk over will eventually disappear after you pick them up. Three are keys and one is a blaster.
Most of the information box stuff is just to make it easier on me later. Saving will be implemented. :P
Speaking of saving, do you think I should rearrange the stasis chambers? The gap between the first and second seems a little spread out.
-
hmm... this looks delicious!
where is that java app of bb's? it looks useful
-
Ah ok, gotcha. I'm guessing the flagged shaped one is the blaster one then?
And what do you mean rearrange them?
Edit:
As for Builder's Java application here (http://www.omnimaga.org/index.php?action=downloads;sa=view;down=516) it is.
-
I've got three stasis chambers, where the user can save their progress. You start out in a stasis chamber
I'm considering moving the second one closer.
And yes, the flag shaped character is the blaster. I think I'll use the pxl-off to make the handle shorter.
-
Here's the original topic for the Java program: http://ourl.ca/4137
And yes, the flag shaped character is the blaster. I think I'll use the pxl-off to make the handle shorter.
Sounds good, just remember that it'll take longer to load each room if you decide to do this. :)
-
Yes, but I'm displaying the keys and blaster separate from the map, so they won't display if you've already picked them up. (This isn't implemented yet, though)
One pxl-off shouldn't take that much longer.
-
Yes, but I'm displaying the keys and blaster separate from the map, so they won't display if you've already picked them up. (This isn't implemented yet, though)
One pxl-off shouldn't take that much longer.
Oh, ok. Then it should be fine from a speed standpoint. :) Good luck getting that implemented!
-
Yes, how'd you guess? :P
The name refers to a surprise twist I have planned for the ending.
Sounds cool as long as it is better than the massive plot twist at the end of the DS version of Drawn to Life: The Next Chapter.
Or the one in Illusiat 12 ;D
(If no one played it, the plot twist after what's supposed to be the final boss is so crappy that it doesn't even deserve a WARNING:SPOILERS notice. Basically, once the battle ends, you escape the final dungeon, but then the father of the boss you just fought appears and you must defeat him. The only reference to him in that 40 hours long RPG is in chapter 3, in an optional area where you find his tomb, with no indication that he will return. Some of my other games have that kind of plot twists too. Typical final battle ending then unexpected mysterious boss or playable character appearing from nowhere. In ROL3 case, an human survivor who now live on the moon with a few other refugee from an attack that occurs in 2200 AD, suddently appears in the middle of the final battle, as your party dies, says Lekens is the chosen then helps him beating the final boss with their new powers. However, that last weird plot twist was in reference to ROL3 sequel, which never saw a single line of code. ANother weird plot twist is in ROL2, but that one can be expected due to small references about someone telling you to not trust a mysterious girl you encountered before.)
-
This won't be severe as that (I don't think), but it should blow your mind.
Yes, but I'm displaying the keys and blaster separate from the map, so they won't display if you've already picked them up. (This isn't implemented yet, though)
One pxl-off shouldn't take that much longer.
Oh, ok. Then it should be fine from a speed standpoint. :) Good luck getting that implemented!
Thanks. Yeah, speed is one reason why I tried to not make the map too big. The other is that 15 rooms is all I could fit on one sheet of graph paper. :P
-
All right. After the first two days of school (and cross country practice) I'll start working more on this. I've got the pxl-offs implemented for the keys, but it makes the blaster handle look too short. Does anyone have a better idea for a sprite for a blaster?
-
Are you stuck on a blaster shape or can it be any gun shape?
-
Really, any gun shape will do. I'm not quite that picky.
-
Ok, well I'm messing with a few things. I did make a cool looking shotgun-ish shape that could be cool. Maybe a machine gun looking one too. I'll post a couple in a minute.
-
Oh, cool. thanks.
-
What I'm showing you is the display one that would require some pixel modifications, and then that first suggestion one that is just the two tokens.
-
Wow, that looks great. thanks again, meishe.
-
No problem. I'm not much of a spriter so someone else might be able to come up with a little better one.
-
This won't be severe as that (I don't think), but it should blow your mind.
As long as it isn't what I planned in Super Star Hero (a game made in RPG Maker 2003 that I started in 2008 but never finished, although it is in the download section). The game occured in 9108 A.D. After the final battle in the computer room (of the final dungeon) the final boss would still be alive and you would be too weak to attempt fighting him again. He would then shoot a laser at you, but it would also hit the computer stuff. This would cause an old radio archive to be played but it would be a rickroll. The boss would not be able to stand that "noise" and would kill himself. :P
-
Thats a nice looking gun sprite actually :) Nice to see my program could find a suitable combo ^^
-
Yeah, the gun sprite actually kind of fits better with what I'm planning.
In the newest version (which I'll upload when I get the time), the character sprite changes when you pick up the gun. What I'm imagining is two guns strapped to the hero's back with handles just over his shoulders so he can grab the handles and pull the guns over his shoulder to point straight out.
-
Nice, can't wait to see the new version in action.
-
This won't be severe as that (I don't think), but it should blow your mind.
As long as it isn't what I planned in Super Star Hero (a game made in RPG Maker 2003 that I started in 2008 but never finished, although it is in the download section). The game occured in 9108 A.D. After the final battle in the computer room (of the final dungeon) the final boss would still be alive and you would be too weak to attempt fighting him again. He would then shoot a laser at you, but it would also hit the computer stuff. This would cause an old radio archive to be played but it would be a rickroll. The boss would not be able to stand that "noise" and would kill himself. :P
lol :P That would've been fun to watch. ;D
Sounds neat MRide. I can't wait to see a screenie! :D
-
Sorry I haven't been able to upload the newest version. I've been a little busy.
I should be able to upload sometime tomorrow.
-
Good luck!
-
Thanks. I finally got it uploaded, and with screenshots!
-
Cool! Will check later :)
Also it looks pretty nice from the screenshots :)
-
Progress will on this will slow during the school year. With three AP classes and cross country, time management will be tough.
But, back to more cheerier subjects. The next update will have saving, moving of a stasis chamber to balance the game out, and a bug fix.
After that, I plan to begin working on some heftier stuff. You may have noticed there is a door to your right that is locked. I'm going to add two more locked doors. These will be able to be opened after completing some sort of puzzle. Right now I'm thinking of having the user connect a path a wires to open the door, but I'm not sure how to accomplish this in BASIC. Any suggestions for a puzzle? Keep in mind that this is set in the future (so no paper clip lock picks), and it should be somewhat relate-able to unlocking a door.
-
Ouch I hope you're not gonna be forced to quit calc stuff completly like Nitacku, Simplethinker and Noahbaby94 last year x.x. Good luck withthe updates. Unfortunately I'm not into puzzle stuff so you may need to ask for Builderboy for that. In Reuben quest, the only real puzzle there were were pushing blocks. In RL1 there was a code to enter somewhere and you had to find clues on 4 tombs.
-
Ouch :( Well best of luck in your future endeavors! As for a door puzzle... hmmm...
Maybe a Basic version of the Key Puzzle from this game?
http://www.notdoppler.com/clickdragtype2.php
Its the first puzzle
-
That looks very nice. Why is there a room with pxl-Text(A0 going through it? It's the room with the broken computer.
Wonderful job! ;D
-
Ouch :( Well best of luck in your future endeavors! As for a door puzzle... hmmm...
Maybe a Basic version of the Key Puzzle from this game?
http://www.notdoppler.com/clickdragtype2.php
Its the first puzzle
Oooooh....that looks cool. Thanks, Builderboy. That's a definite possibilty. It's also the most door related one I've seen.
That looks very nice. Why is there a room with pxl-Text(A0 going through it? It's the room with the broken computer.
Ummmm.... That's a very good question that I have no answer to. I guess I hit a wrong key entering the map data or something. It'll be fixed when I upload the next version. Thanks for pointing that out.
-
Ok, I finally got around to try this. Pretty nice. I'm gonna make a screenshot.
One thing, though: what will be the controls? Also, a glitch occurs at the end of the screenshot, as you'll see.
-
Thanks for making that, DJ. That bug was very weird, but I got it fixed. Also the reappearing key will also be fixed in the next update. It has something to do with the picture variables I use to make map recall much faster.
Also, thanks for the sympathy about my workload. I go to one of the best high schools in my state (19 perfect ACTs in the past five years, 5 in the senior class), so standards are high.
-
Aaah I see, good luck fixing them and good luck with school. Let's hope they aren't way too demanding following school starting.
-
The main character dude reminds me of the movie TRON. :)
EDIT: Just Jackpot'd. 777th post FTW.
-
@DJ: about the controls. the arrow keys will do most stuff. 2nd will be the menu, and clear will exit.
-
What about shooting and stuff?
Also a lil suggestion for when text boxes appear: require pressing 2nd or something, so when we are moving around the box won't dissapear too fast because you held the arrow keys for too long.
-
Well, I was going to have a random encounter system and turn by turn battles.
Thanks for the tip about the info boxes.
-
Oooh I see, RPG style battles. Thanks for clarifying :)
And no problem :)
-
I just uploaded the next update, with an animated screenshot showing the new features.
I had a little trouble with DCS 7, but everything's fixed now.
/me goes off to brainstorm about the key puzzle
-
Nice updates. I like the save points too :)
Keep up the good work :)
-
Good luck with the key puzzle :) It might be tricky but i think it can be done ^^
-
Thanks. I'm rethinking the save zone idea. I'm thinking if the user quits the game, it will save where they are. If they die in battle, however, they will be brought back to the last save zone they used.
-
You should probably ask them if they want to save, in case they end up stuck somewhere they can't get out (like with barely anymore energy left) then inadvertently save their game. That happened to my bro once in Final Fantasy 12, I think.
-
Yeah, that's probably a good idea. I've got my thoughts together about what to do for the key puzzle, and it shouldn't be too slow.
I'm also thinking about making a title screen for the next update, too.
Side note: Is it possible to make a bigger animated screen shot in Wabbit? I finally managed to get my ROM image onto the computer, so I haven't used Wabbit that much.
-
I don't think so. 2x is the only size AFAIK.
Maybe you could bug Buckeye to add screenshotting in various sizes ;D
-
I don't think people will like if people start posting larger screenshots. Just at 2x2 it takes a while to load sometimes. Now imagine for dialup users.
-
True, it's normally more than sufficient. I don't think the .gif format does well when tasked with magnified images.
And if it's too small, you can always just zoom in ;D
-
Yeah, the image itself isn't actually that small, it just looks like it compared to the big ones above it.
-
Also, you can use the img tag size properties anyway. Go to omnimaga.org navbar -> misc-> help-> posting and there is some bbcode info there. However, keep in mind on newer computers resized screenshots looks blurry.
-
I came up with a cool animation for the "Do you want to save?" screen that fits with the computerized theme.
(http://img.removedfromgame.com/imgs/1283035195-IMAGQUESTSAVE.gif)
It's nothing special, I was just happy that it worked. :)
-
Mhmm I do not see any animation in the game ???
EDIT: oh wait you mean how the cursor moves? That looks cool
-
Yeah, like I said, it's not much, but I want to make every aspect of the game look really good. I want to show what pure BASIC can do, and every little bit helps.
-
Have you tried making the cursor animate to the size of the word? So like with yes is would be:
[ YES ]
and no would be:
[ NO ]
instead of:
[ NO ]
-
cursor looks cool. i like the sprites you used for the walls.
-
@meishe: But wouldn't that mess with the animation? Besides, I kind of like it as it is now. It has sort of an old MS-DOS feel.
-
It would depend what you do. I mean it does look great either way, just thought I would suggest it or something.
-
Yeah, thanks for the suggestion, but I think I'll stick with what I have. I really like the DOS look.
Eventually, when I put in a storyline, I'll use the working computers to display text in old monospace font (not that I have another option on the calc):P
-
I like the old skool feel. One thing, though: Couldn't that small menu appear in the same way other game text does? It would probably look a bit more uniform.
-
That looks really nice :D I need to look through this thread later for screenshots and such :)
Edit: Yay! They are all on the first post!
Edit2: These look really nice :D The only suggestion I would have is to maybe make the sprite where you are holding the gun turn, if at all possible. Even with out that, looks amazing :)
-
@DJ you mean the drop down box? yeah, that's probably a good idea.
EDIT: Oops, sorry player, didn't see your post.
Thanks. I'm not sure the right/left option would be useful. Like I said earlier, I'm going to use turn-by-turn RPG style battles. However, I'll work on it. If it doesn't slow the character movement down noticeably, then I'll use it.
EDIT 2: Hmm...I can't seem to find a sprite that isn't symmetrical that looks good. I won't use pixel modification. If someone can come up with a sprite that looks like it has a gun, and can flip vertically I'll use it. (maybe use the little plus symbol, not the character but the one where you can place it anywhere on screen?)
-
I'm not sure what kind of sprite is being asked for.
-
One that can be flipped vertically. it should look like its holding a gun. I'd rather not use pixel modification.
I was thinking maybe something with the little cross you can get with the pt-on command?
Here's one I came up with:
(http://img.removedfromgame.com/imgs/1283114148-Characterflip.gif)
It's not great, but it displays faster than dual-layer.
-
Seems kinda good. I guess you should use it if it displays faster. Just don't use such modification for the tilemap individual tiles, though, as it may make the code pretty large.
-
I kind of like the first one better, but that one allows for the right/left flip. It also takes up less memory. (The plus won't overwrite the X).
The key puzzle is coming along well. Definitely by the weekend I'll have the next update finished.
-
Cool to hear :). Can't wait to try it. I hope it's not too hard, though, lol (I suck at puzzles x.x)
-
Phew. close call. My map program got screwed up and I almost lost all 3840 characters. Luckily, I had the strings stored in memory from the last execution. Disaster averted.
-
OUCH! That sucks when that happen. Hence my backup reminders lately. I'm glad you still got to save your map in extremis at least.
-
Isn't wasn't really bad at all. I just ran the program, and DCS came up with an error message. The first layer data was all messed up and the second layer was gone, but I only had to recall two strings and everything was fixed.
-
Well, I've basically finished the key puzzle program. It's very similar to the game in the link Builderboy posted. You lower the teeth on a key, and insert into a lock. If all the wires or whatever line up, the lock opens. The trick is, you can't raise the teeth on the key, only lower them. The user can toss their old key and get a new one, but they only get three keys.
Currently, I've got the height of the wires at a set length, so it's the same if you try again (after you use all the keys). I'm considering making the wire heights random, so if they use up the keys and try again, the puzzle will be different. Suggestions?
-
Interesting puzzle. I think you should make the wire heights random, though, so people who played the game or saw someone play won't already know a combination.
-
Yeah, I'll probably do that. I was also considering adding difficulty levels (2 keys, 1 key).
I'll post a screenshot when I can. Now I'm off to come up
with ideas for the title screen.
-
Difficulty levels sounds cool. ^^
-
All right, here are a couple screen shots of updates. The first one is of the key puzzle, and the second one is of an idea for a title screen.
(http://img.removedfromgame.com/imgs/1283548494-IMAGQUESTKEY.gif)
(http://img.removedfromgame.com/imgs/1283548522-IMAGQUESTTTL1.gif)
While I think the title screen looks cool, I'm not sure that it matches everything else. The flowing script doesn't really go with futuristic/computer stuff. What do you guys think? I'll work on a more square, computer-like font to compare.
-
Those look really cool! The only thing with the key game is that do you not get to see the key heights first? Because how are you supposed to know what to guess at first?
-
Just try the key first thing. There isn't a penalty for guessing.
Here is the rules
You lower the teeth on a key, and insert into a lock. If all the wires or whatever line up, the lock opens. The trick is, you can't raise the teeth on the key, only lower them. The user can toss their old key and get a new one, but they only get three keys.
-
Well I know but since you only get three keys wouldn't that be wasting one?
-
No, you can try a key as many times as you like. You would need a new one only if you lowered one of the teeth too far.
-
Oh, so you only waste a key if you go to down to far on one of the teeth?
-
Yeah, so the puzzle isn't actually too hard once you get it.
Which is why I'm probably going to add difficulty levels, so you'll only get 2 keys or just 1 key.
-
Nice screenshots, but I think the key pins should not be filled black, because it kinda looks slightly like a toothbrush to me. Seems nice in overall though. As for the title screen, it's nice too, but yeah, maybe no italic, and maybe use a more square font so it looks more futuristic
-
The reason I made the teeth filled in black was to distinguish them from the pins/wires in the lock. Would it look better if the pins/wires were filled in instead?
-
yeah I think it might be a good idea. You should post another screenshot looking that way. What do other people think?
-
The only problem I would see with that would be the little wire section on top of the pin would look confusing if the lock pin was the lowest height. (Then it would be close to the key tooth)
-
I actually like how it right now.
-
Here is the new title screen. The letters are supposed to appear like that, to simulate typing. It just looks a little fast on Wabbit.
(http://img.removedfromgame.com/imgs/1283606986-IMAGQUESTTTL2.gif)
-
Nice, I like those even better. I also like the way it appears :D
-
Yeah, it appears slower on calc, and it really looks like typing. If I feel like it, I might add a cursor, too.
-
That looks really cool. Is it possible to make the type face a little more bold? I think that might make it look a little more computer-like (well, old computer-like) :)
Is each letter set to a specific timer or is it a random routine so it's different each time?
-
A cursor would be cool, actually. Would look a bit like the rest of the text ^^
-
Those are looking really cool! I really like the way you made the key puzzle work out in Basic, it really looks nice :) And the title screen is also great! I like the way the title is displayed, and the 'font' if you will. Great job on all of this!
-
Thanks, Builderboy
Is each letter set to a specific timer or is it a random routine so it's different each time?
It's a specific timer. I still need to fine tune some of them, though.
-
So, I'm going to attempt to add the ability to face right or left. Unfortunately, this is a little difficult.
I have two options. The first is to start with a regular X, and when the gun is picked up, do this for the flip:
(http://img.removedfromgame.com/imgs/1283717162-IMAGQUESTOPTION1.jpg)
Or, I can do this, where the first sprite is the original character, and the next two are after the gun is picked up.
(http://img.removedfromgame.com/imgs/1283717231-IMAGQUESTOPTION2.jpg)
Or, if you have any other ideas, I am open to suggestions.
-
Not to be impatient or triple post or anything, but...*bump*
-
Sorry, shit happened since yesterday, so I didn't catch up til now.
I personally like the second idea better. What combination of char did you use, btw?
-
I don't think there are combinations for the second two. But the first one can be done by using "X" and "'."
-
Actually, both are possible. If you use Pt-on(X,Y,3) It makes the mark a cross, which is what I use.
-
Oh ok. I was just talking about Dual Layers.
-
I haven't posted here in a while, but this project is still alive. I sorted out the sprite flipping, and now I'm working on speed. The character movement was getting pretty slow, but now the loop has a couple hundred less bytes to read through each iteration. The speed still needs improvement, though.
After that, I'm going to work on the storyline.
-
Nice to see more progress. As for speed, my guess is that if it gets too slow, you may be forced to eliminate any non-Text()/recallpic display from the walking loop, even if it means the char is the same for all 4 directions. Just Pt-On/off is enough to slow down a basic game considerably :(
-
couple hundred bytes? Wow thats a lot of data shaved off, just how much is left in the loop after that?
-
What kind of stuff did you end up removing? The GAME? (Sorry DJ, had to take your idea :P)
-
I just got a chance to look at the Key Puzzle and Title Screen. They look wonderful! How did you make the title screen letters like that? :)
-
What kind of stuff did you end up removing? The GAME? (Sorry DJ, had to take your idea :P)
Well, the hit detection and room changing routines were put into their own subprograms, and are only called when needed.
Nice to see more progress. As for speed, my guess is that if it gets too slow, you may be forced to eliminate any non-Text()/recallpic display from the walking loop, even if it means the char is the same for all 4 directions. Just Pt-On/off is enough to slow down a basic game considerably :(
Just for fun, I tried eliminating everything that had to do with sprite flipping, and the movement was considerably faster. It had gotten so bad, you could see the individual characters for dual layers if you looked closely.
couple hundred bytes? Wow thats a lot of data shaved off, just how much is left in the loop after that?
Well, there's the walking routine, the character display routine, and calls to the hit detection and room changing subprograms.
I just got a chance to look at the Key Puzzle and Title Screen. They look wonderful! How did you make the title screen letters like that? :)
Thanks. I just used a lot of line( commands. I used a set height and width for each letter (expect for the beginning of each word), and it wasn't too hard.
Not that it means a lot, but I got everything I have up to this point working in conjunction. So the only things I have left are storyline and battle system. (and maybe a few minor things)
-
For the title screen is everything hard coded in with each line having it's own command or are the coordinates compressed at all?
-
X.x, that sucks BASIC is so slow. Oh well, at least games like yours and a few others here shows that BASIC can still make cool games at least ;D
Nice to see this is still progressing. Can't wait to see battle system :)
-
For the title screen is everything hard coded in with each line having it's own command or are the coordinates compressed at all?
No, no compression. Would that be any slower? The title screen effect requires fast displaying letters.
X.x, that sucks BASIC is so slow. Oh well, at least games like yours and a few others here shows that BASIC can still make cool games at least ;D
Nice to see this is still progressing. Can't wait to see battle system :)
Thanks. I really would like to have flipping, but after seeing the severe speed decrease, I just did away with it.
You might have to wait a while for the battle system, though. Progress is going to really slow down now that school is on a roll with tests and everything.
-
For the title screen is everything hard coded in with each line having it's own command or are the coordinates compressed at all?
No, no compression. Would that be any slower? The title screen effect requires fast displaying letters.
Compression would take too long. How big is it now? :)
-
For the title screen is everything hard coded in with each line having it's own command or are the coordinates compressed at all?
No, no compression. Would that be any slower? The title screen effect requires fast displaying letters.
Compression would take too long. How big is it now? :)
Well, let's see....the whole title screen program is about 1400 bytes, so maybe 1000 bytes of line( commands.
-
Well if lists were used to store the coordinate data wouldn't that save room? I have no idea though, was just a thought.
-
Well, let's see....the whole title screen program is about 1400 bytes, so maybe 1000 bytes of line( commands.
Ah, okay. :)
Well if lists were used to store the coordinate data wouldn't that save room? I have no idea though, was just a thought.
I doubt if it would save much space, but it would be slower. You could make it smaller with strings, but that would be slower as well. :)
-
How much slower though? I can't imagine it making it to bad.
-
I think it would be possible to get good speed with strings. Hmm... :)
-
Hmm, ya. A string would also be easier to code.
-
You could actually probably get decent compression with lists, plus they'd retain a fair amount of speed, if done right. (Contra 83 style!) Each line would be one list element, and you can actually draw it fairly quickly for compressed stuff in BASIC. I believe I posted an image editor that lets you draw images in that form of compression, and includes the drawing routine somewhere in the sprite request thread for this.
-
Ya, thats what I was thinking too. And honestly I think lists and strings would both work. It would just be a matter of testing.
-
So, how would I do this with lists? Store the coordinates in lists and use a for loop with a random wait at the end for the typing effect?
-
Well with lists there are a couple ways you could store to them. You could do either one set or coordinates per element or you can store up to six or seven coordinates per element. For example, if you did one set per element it would look something like {1020304,5060708,9101112,...} and then use a combination of 10^( and multiplying by a hundred to pull the right coordinate. The timing might be a little hard this way. If you did six or seven coordinates per element then you could do {1020304050607,8091011121314,15161718192021,...} and do a similar method to decompress it.
If you give me a list of coordinates, in order of how they would be displayed, I can put together an example of what I mean in action.
Also, for the string method. It's more obvious with it but I'll explain anyways. You'd basically just line them up in order of being displayed, such as "010203040506070809101112131415161718192021...", and then use a For( loop going from one to the length, minus three I think (three or four), going up by fours and just use the sub( to call the correct coordinates.
-
Here's the coordinates for the first letter.
1,-2,9,-2
5,-2,5,-7
1,-7,9,-7
-
{1020902,5020507,1070907→L1
For(A,1,dim(Ans
Line(iPart(E2fPart(L1(A)/E8)),-iPart(E2fPart(L1(A)/E6)),iPart(E2fPart(L1(A)/E4)),-iPart(E2fPart(L1(A)/E2
End
Note:
Each "E" in that code is the scientific notation E.
"010209020502050701070907→Str1
For(A,1,length(Str1)-7,8
Line(expr(sub(Str1,A,2)),-expr(sub(Str1,A+2,2)),expr(sub(Str1,A+4,2)),-expr(sub(Str1,A+6,2
End
There might be optimizations that can be made, I just threw those together real fast to demonstrate the methods.
Note:
The list method is 108 bytes while the sting is 114 bytes. BUT, the string is 35 bytes while the sting is 39 bytes.
-
Note that i would recommend Lists, as in experience i have found it to be faster than Strings. However if size is what you are optimizing strings are better.
-
Wait, lists are slower than lists? O.o Did you mean that strings are slower than lists?
Nevermind, you fixed it :P
-
Haha yeah didnt you hear? If you use Lists, they are by nature slower than themselves, which means they are also faster than themselves, which means you can get infinitely fast or slow speed at the same time :D
* Builderboy hits self with a pointy thing *
-
For once TI-BASIC is faster than assembly then ;)
-
{1020902,5020507,1070907→L1
For(A,1,dim(Ans
Line(iPart(E2fPart(L1(A)/E8)),-iPart(E2fPart(L1(A)/E6)),iPart(E2fPart(L1(A)/E4)),-iPart(E2fPart(L1(A)/E2
End
Note:
Each "E" in that code is the scientific notation E.
"010209020502050701070907→Str1
For(A,1,length(Str1)-7,8
Line(expr(sub(Str1,A,2)),-expr(sub(Str1,A+2,2)),expr(sub(Str1,A+4,2)),-expr(sub(Str1,A+6,2
End
There might be optimizations that can be made, I just threw those together real fast to demonstrate the methods.
Note:
The list method is 108 bytes while the sting is 114 bytes. BUT, the string is 35 bytes while the sting is 39 bytes.
Thanks, that makes sense to me (I think).
Also, I think you lost the game, Builderboy. (and if you didn't, you did now. :P)
Oh, and look at this!
-
{1020902,5020507,1070907→L1
For(A,1,dim(Ans
Line(iPart(E2fPart(L1(A)/E8)),-iPart(E2fPart(L1(A)/E6)),iPart(E2fPart(L1(A)/E4)),-iPart(E2fPart(L1(A)/E2
End
Note:
Each "E" in that code is the scientific notation E.
"010209020502050701070907→Str1
For(A,1,length(Str1)-7,8
Line(expr(sub(Str1,A,2)),-expr(sub(Str1,A+2,2)),expr(sub(Str1,A+4,2)),-expr(sub(Str1,A+6,2
End
There might be optimizations that can be made, I just threw those together real fast to demonstrate the methods.
Note:
The list method is 108 bytes while the sting is 114 bytes. BUT, the string is 35 bytes while the sting is 39 bytes.
Thanks, that makes sense to me (I think).
Also, I think you lost the game, Builderboy. (and if you didn't, you did now. :P)
No problem. Like I said you can put two more coordinates per element if you want. You just need to do a little tweaking to the program.
-
Haha yeah didnt you hear? If you use Lists, they are by nature slower than themselves, which means they are also faster than themselves, which means you can get infinitely fast or slow speed at the same time :D
* Builderboy hits self with a pointy thing *
lol :P
So, MRide, did you decide on lists or strings? Either way, I think it'll be fine. :)
-
Well, if lists are infinitely fast.....j/k :P
I'm going with strings.
Well, just tried it. Definitely slower, so I won't add the random delay, but the effect is kind of cool looking.
Now that this is done, I can resume working on the story. (And damn, text takes up a lot of mem)
-
Do not use lowercase letters if possible. Each take 2 bytes while uppercase takes 1 each. And yeah text is large :/
-
I'm using the graph screen, so lower case won't be necessary.
-
Wow. I tested to see how much RAM my game is taking up. I halted execution midprogram, and I had 5k RAM left. That means at some point in the execution, I have 5.2k bytes left in RAM! And I haven't even completed the storyline program or written the battle engine yet. I'm probably going to have to make this into an app with BasicBuilder, if I want it to be playable.
-
BasicBuilder on does one page apps I believe, so that won't do a whole lot in terms of helping with memory. You might have to use XCOPY or something.
-
I would recommend against BasicBuilder since you can only have 1 page apps and it's a major PITA to add pics if you use any, or archived programs. XCOPY seems like a better bet for a project like this. See Illusiat 13, for example.
-
I generally do not recommend BasicBuilder. I find that it slows down programs with too many subprograms, and it gives you no extra Ram options either. I much favor Xcopy, since it gives you much greater memory options and is really fast
-
Well, okay then. :P I'll look at xcopy.
-
The storyline is coming along well. Now when you turn on a computer, you get a data log with a part of the story of the building you are in. It's kind of like Desolate. I also wrote the intro program with a cool text-scrolling thing like Serenity.
So pretty much all I have left is the battle engine (oh boy) and a way to actually win the game. :P
-
Good luck on the battle engine! That's always the hardest part. :)
-
Nice to see more progress. Btw for the text scrolling, if you don't mind the calc turning OFF when left idle for a while and if you don't mind ENTER being the confirm key, you can save a lot of memory by using Pause "Extermly long Text Pause allows you to scroll"
-
Nice to see more progress. Btw for the text scrolling, if you don't mind the calc turning OFF when left idle for a while and if you don't mind ENTER being the confirm key, you can save a lot of memory by using Pause "Extermly long Text Pause allows you to scroll"
lolwut?
The text is scrollable on the last line of the homescreen. You can go either forward or back and read at your own speed. Oh, I see what you were saying, no, I mean scrolling left to right. It's not really a lot of text.
Good luck on the battle engine! That's always the hardest part. :)
Thanks. I've got some cool sprites from shmibs, so I'm hoping this will turn out pretty cool.
-
Nice to see more progress. Btw for the text scrolling, if you don't mind the calc turning OFF when left idle for a while and if you don't mind ENTER being the confirm key, you can save a lot of memory by using Pause "Extermly long Text Pause allows you to scroll"
lolwut?
The text is scrollable on the last line of the homescreen. You can go either forward or back and read at your own speed. Oh, I see what you were saying, no, I mean scrolling left to right. It's not really a lot of text.
What is the lolwut for? Care to explain? I was simply giving a suggestion for coding.
-
Nice to see more progress. Btw for the text scrolling, if you don't mind the calc turning OFF when left idle for a while and if you don't mind ENTER being the confirm key, you can save a lot of memory by using Pause "Extermly long Text Pause allows you to scroll"
lolwut?
The text is scrollable on the last line of the homescreen. You can go either forward or back and read at your own speed. Oh, I see what you were saying, no, I mean scrolling left to right. It's not really a lot of text.
What is the lolwut for? Care to explain? I was simply giving a suggestion for coding.
I'm guessing that that was his reaction as "What is the great coder DJ Omni doing telling me to use Pause for?! I've never used Pause like that. *Time passes* Oh! The great coder Rick Astley (DJ) is teaching me how to make my game win and this will be the game that everyone loves if I pause like this! I must celebrate with the feasting of Nethams!" or something like that. ^-^
-
Nice to see more progress. Btw for the text scrolling, if you don't mind the calc turning OFF when left idle for a while and if you don't mind ENTER being the confirm key, you can save a lot of memory by using Pause "Extermly long Text Pause allows you to scroll"
lolwut?
The text is scrollable on the last line of the homescreen. You can go either forward or back and read at your own speed. Oh, I see what you were saying, no, I mean scrolling left to right. It's not really a lot of text.
What is the lolwut for? Care to explain? I was simply giving a suggestion for coding.
I'm guessing that that was his reaction as "What is the great coder DJ Omni doing telling me to use Pause for?! I've never used Pause like that. *Time passes* Oh! The great coder Rick Astley (DJ) is teaching me how to make my game win and this will be the game that everyone loves if I pause like this! I must celebrate with the feasting of Nethams!" or something like that. ^-^
Something like that. :P
-
Ah ok, well
Pause "stuff"does like Disp "Stuff"except that if it's longer than 16 characters, you can scroll left/right
-
Ohhhhhh....ok. I guess that means the routine I wrote is kind of redundant..
-
Well not necessarly. With Pause, you need to use ENTER to continue. It can be good for pausing the game or saving space, but the problem is that you cannot use whatever key you want (like 2nd).
-
Yeah, but with pause, the routine is 88 bytes smaller....
-
Ok it's up to you then. if you require ENTER, make sure you keep controls consistent, though. In FFTOM, some menus required to press 2nd to confirm then you had to press ENTER to continue x.x
-
Screenshot!
Here is the basic layout of the battle screen. The version is a little old (now it displays the sprites right to left and fills both health bars at the same time), but the final screen looks the same.
I'll also put this in the first post for convenience.
All credit goes to shmibs for the sprites, and thanks to meishe for his compression program (and display routine)
-
That looks great! Are actually using the programs I gave? I was just curious because they get displayed differently than how mine do and all.
-
O.O
Holy crap! That looks great! I am amazed at how fast the sprites are generated and how complex they are while being generated that way. How large are each sprite, though?
Keep up the good work on this project! :)
-
Wow, that's epic. Excellent job MRide! ;D
-
That looks great! Are actually using the programs I gave? I was just curious because they get displayed differently than how mine do and all.
Yeah, I am. I just sorted the list ascending. (in the screenie its actually descending)
O.O
Holy crap! That looks great! I am amazed at how fast the sprites are generated and how complex they are while being generated that way. How large are each sprite, though?
Keep up the good work on this project! :)
Thanks. :) Rough estimate: about 25 pixels wide, 30 pixels tall.
Wow, that's epic. Excellent job MRide! ;D
Thanks. The sprites are all shmibs work, though (and the unseen work of meishe for compression)
I actually have more done than this. I've got a lot of the formulas worked out, but as you can't actually attack yet, there isn't a way to show it.
-
Ah ok, cool :) I didn't even think about sorting the lists. It just looked different because it seemed like there were vertical and horizontal lines and such. So are you using lists or strings for your compression? I've been working on a few different programs that might be able to make them smaller and such.
-
Lists. I was being stupid and put the coordinates for the hero and evil scientist dude in one list, though. Now I'll have to find where the jump is and separate them.
-
Well you could just save the screen with both of them into a picture variable, run my program, put that list into another, then run it on the other sprite. Would save you some work of going though it.
-
Well you could just save the screen with both of them into a picture variable, run my program, put that list into another, then run it on the other sprite. Would save you some work of going though it.
Hmmm? I want two separate lists. The hero one will always be used, and the enemy ones will change. It would be very mem-wasteful to have combos of all the characters.
-
Oh, so you mean you want one list that has just the hero and then a list that contains the enemies?
-
That looks great! Are actually using the programs I gave? I was just curious because they get displayed differently than how mine do and all.
Yeah, I am. I just sorted the list ascending. (in the screenie its actually descending)
O.O
Holy crap! That looks great! I am amazed at how fast the sprites are generated and how complex they are while being generated that way. How large are each sprite, though?
Keep up the good work on this project! :)
Thanks. :) Rough estimate: about 25 pixels wide, 30 pixels tall.
I meant memory-wise. ;D Are each sprites 8 KB, 16 KB, etc?
-
Oh, I really don't know. You mean the drawing routine?
-
That looks great! Are actually using the programs I gave? I was just curious because they get displayed differently than how mine do and all.
Yeah, I am. I just sorted the list ascending. (in the screenie its actually descending)
O.O
Holy crap! That looks great! I am amazed at how fast the sprites are generated and how complex they are while being generated that way. How large are each sprite, though?
Keep up the good work on this project! :)
Thanks. :) Rough estimate: about 25 pixels wide, 30 pixels tall.
I meant memory-wise. ;D Are each sprites 8 KB, 16 KB, etc?
You had sprites that took 8/16 KB? O.O
-
Yeah, that's what I was wondering.
-
Ya. By the way, did you see what i asked about the lists?
-
Oh 8 KB was a bit overexagerated. I meant how big is the sprite data in general, in terms of memory? Are each sprites 200 bytes?
-
SWEET! i love it!
does this mean i'll be making more enemies for fighting?
-
Oh, so you mean you want one list that has just the hero and then a list that contains the enemies?
Or just separate lists for each one.
SWEET! i love it!
does this mean i'll be making more enemies for fighting?
Well, I only requested the two aliens (how's the second one coming, btw?), but if you want to make more go ahead. :) I'll be happy to implement them.
EDIT: 300th post!!!
-
Well what you can do is either make separate lists for each enemy or if you want them in the same list you can use augment( to tack lists onto each other and then when a enemy is chosen set a couple variable for the start and end of that enemy.
-
Yeah, but I still need to separate the hero from the enemy, though. I'll think about your suggestion. Would that make the routine any slower? (Also, what's the limit on number of elements in a list?)
-
Ya, I know. That's why I said just to rerun my program with the hero on the screen. That way you get a list with just him in it. It shouldn't, I don't think. You can have only 999 elements in a list.
-
But I still have to separate the scientist one too. (Which I don't have a pic of) I think it would be easier just to go through the program and find the split.
-
Well what I was saying is run your program that displays them. Stop execution after they are done with the sprites. Save the screen as a picture. Then run the program twice, storing to different lists. That's what I meant originally. That way you get your hero in one list and your enemy in another.
-
Ah, I see. Yeah, that would probably be easier. (Before I was just having the program check the whole screen b/c I was lazy)
-
That's why I made it so you can insert coordinates and size ;)
-
Alright, here is a much better screenie with my new display method (using cool Boolean logic), and this time its actually got the correct, randomly generated enemies. Thanks to shmibs for the sprites and meishe for his compression routine.
-
Woah! That's great! I need to check the progress on this more often! :D
-
Nice :D
You still didn't answer my question, though. How much memory does each enemy sprite take? I was wondering since if each takes 500 bytes for example, if you got 40 enemies or something you'll run out of memory pretty fast.
-
That looks great! Nice job! ;D
-
40 Enemies? O.o I've got those two and the scientist. Just that program takes almost 8000 bytes.
-
That's looking really sweet!
-
Just that program takes almost 8000 bytes.
Just the enemies/scientists takes 8000? O.O
-
Well they are stored into lists and each list is probably about 120 or so elements.
-
Ah ok. I was just a bit worried about lack of RAM in the future. Are you still planning to use XCOPY?
-
Well, doesn't that just move the programs from archive to RAM? Is there a program that creates an app (besides Basicbuilder), with options for multi-page apps? It would remove a lot of clutter from the program list.
-
It copies them to RAM (and lets you delete the copies when not needed anymore). And sadly, nope, no such app program.
Alternatively, if memory poses an issue if you add more enemies, you could just keep your enemy data in lists format and archive/unarchive them when needed, although if the random battle rate is high and grinding is required a lot, it might causes a lot of Garbage Collections for regular 83+ users.
-
Alternatively, if memory poses an issue if you add more enemies, you could just keep your enemy data in lists format and archive/unarchive them when needed, although if the random battle rate is high and grinding is required a lot, it might causes a lot of Garbage Collections for regular 83+ users.
And it would take a while to Archive the data on the other calcs after the Archive is "saturated" with many copies of the lists. :)
It's a great idea, though. ;D
-
Nooooooooooooooooooooooooooooooooo
There goes my hope of a pure BASIC game. :(
-
Why? You can archive and unarchive external lists in basic; Xcopy is Asm, though. =/
-
Exactly. I'm pretty sure I have >24kb of programs on my calc right now.
-
Ah. =/ Good luck with making it all fit. :)
-
I see, good luck. Of course if you can manage to make as much stuff as possible into data then you might be fine. If you have lots of text, it would mean sacrifying several string vars and having to include them with the download, though. The advantage would be that you could bypass the 24 KB limit easily.
-
Have you gone over your code and optimized it and such or had someone else look over it? That could help save more space and such.
-
I've decided to reveal some of the storyline while I've got some free time.
The game starts with the hero waking up in a laboratory of some sort. He has no idea how he got there. Unfortunately for him, the laboratory happens to be populated with mutated creatures. The point of the game is to escape the laboratory. The twist at the end will blow your mind.
Also, DJ, the sprite drawing program is only 5400 bytes, and that includes drawing the entire screen and the loop.
-
cool! so the laboratory is REALLY big then, I take it?
-
Well, fifteen screens. I know the plot doesn't seem very long, but think Desolate
-
I've decided to reveal some of the storyline while I've got some free time.
The game starts with the hero waking up in a laboratory of some sort. He has no idea how he got there. Unfortunately for him, the laboratory happens to be populated with mutated creatures. The point of the game is to escape the laboratory. The twist at the end will blow your mind.
Also, DJ, the sprite drawing program is only 5400 bytes, and that includes drawing the entire screen and the loop.
Awesome! As for the size of the sprite program, I assume this includes the sprites themselves too? if not, then how much bytes of sprite data do you currently have?
-
Thanks. and yes, the program contains the sprite data, too.
-
Cool, so that's kinda small so far :D
-
Small update. Good news: the battle system will be bigger and better than I originally thought. Here's what I'm doing. I wanted to do something a little different. There will be no levelling up, only a battle count. The hero has different attacks, depending on whether he has a gun and his battle count. The monsters will each have their own attacks, the power of which depends roughly on the battle count.
-
Nice. Can't wait to see this :)
-
Aaah nice to hear, I assume the lack of leveling up will still let you improve/master your character though, right? Also what will you make sure there won't be abuse of weak enemies to easily improve your chars? In Final Fantasy II for the NES you could get at 6000 HP early in the game x.x
-
The enemy difficulty will be based on the battle count. Also, you'll get new attacks after winning a certain number of battles, but things like damage and health will increase with each battle.
-
Ah ok, kinda like Final Fantasy 8, then. Just make sure that increasing your stats has a purpose in the game, such as the new attacks you are talking about or newer enemies being impossible to beat early in the game. In other words, just make sure someone can't simply escape every battle except bosses then go straight to the final battle without training himself.
-
Well, the battle count is only.for battles you've won, so the enemies won't necessarily get harder (I'll add something to make their difficulty increase a little, though). The final boss will be a set difficulty, though, so training is definitely required.
-
Ah ok, I see. Sounds good then :)
-
Sounds neat! ;D
By the way, have you seen this: http://ourl.ca/3839/69999
It's what I use to edit my maps in Elmgon. ;D
-
That looks nice, Z. The maps are all finished for this one, but I'll definitely be using that for IQ 2: Reality. Shifted dual layers are kind of hard to edit in the program editor.