748 replies to this topic

[sometimes99er]

Opry99er, on Tue Feb 15, 2011 9:25 PM, said:

I suppose I could leave all the non-landscape stuff completely out of it and just display them when necessary.

Yep, I would do that. For a pure assembler version I would do the background landscape and draw objects upon this. Objects would then have these status bits about being there or not (apart from info about screen no. and location).

[Opry99er]

I suppose that's the route I'll have to go... It would prevent me from having to poke values into memory... =)

[Opry99er]

**Updates 2-16-11**

1) Thanks to Matthew's new tool, TIdBiT, I have a working menu system. =) It's just the root, so far... a skeleton structure, if you will... But it works beautifully and it's fast fast fast. =)
I'll make up a video when my full menu system is complete.

2) Implemented a variable structure for all the character battle statistics.

3) "Item" handling structure is in place, but is a work in progress.



Pretty sure I will need a file on diskette for transferring statistics and items between XB programs. As things currently sit, each world will consist of its own XB program, it's own assembly support routines, and it's own textfile for internal dialogue, narration, etc...

Doing some calculating, I will need at multiple disks, but not 100% sure how many. Each world will be similar in size, some larger than others... Please see my new thread about program and file sizes.

[Opry99er]

**Updates 2-16-11 v2.0**

I wanted to take a second to lay out what I'm planning on doing with this project OUTSIDE the main program code.

1) Introduction sequence: a short "film" Text blended with bitmap images to give the story of the game.

2) Intermissions: Between worlds, I want to have another page or two of images and text to update the player as to the story... similarly to how games such as Final Fantasy have animated sequences with text to tell the story.

3) Docs on Disk: The game will come with a paper manual and a map, but I would at least like to have the bare bones information in DV80.

4) Save: This is proving to be a tough cookie to crumble for me, mentally... I need to find a way to parse the data to a file--- then read it from the file and re-integrate it into the program. I've done a few little things like this, but nothing to the scale I'll need to implement here

**I realize this is pretty ambitious, but I'm building the framework now and I feel pretty confident that I can get this stuff knocked out in time. I'm dreaming code again. =) It's been awhile since that happened.

[Opry99er]

Here's a short video I posted to Matthew's thread already... wanted to post it here for continuity as well. It shows the use of TIdBiT to help build the rough menu skeleton.

[JamesD]

TIdBit looks a lot like a program someone wrote for the CoCo. I think it was called Urbane Basic.

[Opry99er]

This weekend was a good opportunity for me to step away from the keyboard and think.  I have figured out the next few steps and here they are:

1) design several templates for menu 
2) set up draw routine for menu screen
   **I will try my best to do it fast in XB
3) set up efficient routines to change character sets between exploration/battle/and menu

These will be the next elements to be implemented into code.  The trick is getting all this stuff to be "fast".  We can draw an entire bitmap screen in assembly in microseconds, but a couple of CALL HCHARs in XB are visibly noticeable during program execution.  

So we'll see how quick/clean we can make this look--- I want to trick the player into thinking like, maybe we got 255 tiles to play with here.... When in reality, we're just being thrifty and recycling.  . More to come:

Edited by Opry99er, Sun Feb 20, 2011 2:22 PM.

[Opry99er]

Okay--- Rich, my good buddy (and very talented one) has helped me with some new Beryl graphics... See below. I will be using a "right and left" facing Beryl character, I think... two SPRITEs overlapped.

If Beryl is walking north or south, he will retain the pattern of the direction he last faced. This is pretty exciting stuff, so I wanted to share it here.

Edited by Opry99er, Wed Mar 2, 2011 1:54 PM.

[sometimes99er]

Ah, that must be "UnderExtended". He is truly a master of pixels. It would be nice, if he would post some of his work here. I've seen like maybe a hundred characters and vehicles of his, and they range from pretty good to totally unbelievable. I would like to put some of his graphics to use in demos and games. I suggested we'd do Planet Patrol, but I guess life got in the way.

[Opry99er]

UnderExtended. =) yep... I really enjoy his work and am jealous... hehehe

[Opry99er]

Planet Patrol looks pretty awesome. =)

[sometimes99er]

This was the only non Atari cart I had for the 2600 back in the day. I had at least 30 carts. I don't think I played it much though.

It looks quite doable as a TI-99/4A clone. All elements could be implemented and maybe improved a bit - at least graphically. And apart from similar soundeffects, we could have music and fanfares. Distribution of moveable objects fits the VDP sprites very nicely (also respecting the 4 sprite horizontal limit), and background graphics could actually compliment sprites with more colors - if you really wanted to get all that fancy. An alternative could be a somewhat realistic ground background (moving or not).

[Opry99er]

Posted a quick update video...

[Willsy]

Yep. Got to say, this looks like it's seriously starting to take shape now. I know you've been working on this for a long time, just like me with TF. Keep at it. It's starting to come together. You've really got something. Proud of you, Owen. Congratulations!

Mark

[Opry99er]

Thank you, Mark. =) Coming from you, that means a whole lot. Soon, I hope to have a playable demo for you guys... shouldn't be more than a couple months. I want to be finished by the Faire.. =) Maybe we'll demo our two projects on the same day up in Chicago. =)

[Opry99er]

Through some careful compacting, I have decreased the size of my main game code down from 6.5k to about 4k. =) It might not sound like much, but there's about to be 6k of text crammed in, so I needed to get all my ducks in a row. I was surprised how much space I saved by replacing text with string variables... All the repeated menu prompts are handled by strings, and now all interactions that take place during "examine" draw from pre-set strings... example below...

166 EX$="PRESS ENTER TO EXIT"
167 BS$="BROADSWORD"
168 TC$="TREASURE CHEST"
.
.
2500 IF Q=115 THEN IT$=BS$ :: GOTO 3000 .
.
3000 DISPLAY AT(1,1):"YOU FOUND A ";IT$;:"ADD TO INVENTORY? (Y/N)";
.
.
3510 DISPLAY AT(8,1):"ITEMS";:: DISPLAY AT(12,1):EX$;

Anyway, it's getting very clean now. Thought I'd share the fun. =)

[Vorticon]

Nice work Owen This is going to be a very exciting Faire in November!

[Opry99er]

Looks like I'll have to wipe out my last available character set and the remainders of 3 other sets to get this player graphic done... This leaves little to no room for other graphics: swords, potions, etc... It's okay though... Most of that can be done in the menu, which redefines about 3 character sets anyway (since no "landscape" graphics are needed in the menu)... During exploration, I will probably have to have one universal tile for "something"... When you "examine" the item, it will tell you what that particular "something" is. This will render useless the GCHAR call during the examine routine.... But since I will be placing items on screen after the screen is "drawn" or "scrolled to", this is actually okay.

It just won't be as visually appealing.

[sometimes99er]

How about making your tree of wisdom one character only. Making it more difficult to spot = not too obvious = more challenging ?

[Opry99er]

An interesting thought. Maybe a tile and a SPRITE over top of it--- give it some colour and depth. that would help alot, actually.... Thanks for the suggestion!

[Opry99er]

Working with different ways to save game variables to disk and retrieve them. The code snippit is the "meat". I also made a short video with some extra stuff in there to explain what's happening step by step.

100 BSPD=5 :: BGLD=100
110 OPEN #1:"DSK1.BERYL",UPDATE
120 PRINT #1:BSPD:BGLD
130 CLOSE #1
140 CALL CLEAR
150 BSPD=0 :: BGLD=0
160 OPEN #1:"DSK1.BERYL",UPDATE
170 INPUT #1:BSPD,BGLD
180 PRINT "BSPD:",BSPD:"BGLD:",BGLD

[Bones-69]

As another thought, if you have lots of variables in arrays you can also put them into a single (or couple) of strings, then save the string/s to disk.

For example (where A(n) is your array);

FOR I=1 TO 50::A$=A$&STR$(A(I))&"#"::NEXT I::PRINT #1:A$

When you want to retrieve or save the data you only have to read one or 2 records. Then you can use LEN$, SEG$, POS and VAL to put the data back into the array where it belongs. The "#" is used to flag the end of one variable and the start of the next (so the value or length of A(I) is of no concern).

I haven't done the test for speed but I am quite sure it is much quicker to read a single string and then process the string from within the program rather than (in this example), read/write 50 different records and allocate each one as it is encountered.

Not sure how many variables you will be dealing with but on the assumption it is quite a few, this might help speed things up quite a bit during the SAVE/LOAD routine.

[Opry99er]

Over a month old... Hope it doesn't disappoint. This has been enhanced and some kinks worked out... also have the battle engine VERY close to done. Anyway, please enjoy!

[JamesD]

"Like"