The Legend of Beryl Reichardt

[matthew180]

Ahhhh, I now have working boundaries!!! just need to modify my map data so you don't see the machine junk around the edges of the map when you get close. I just need to add a couple rows of lava to the top and bottom and then a few extra bytes of lava to the beginning and end of each "row" and then BAM!!! I'll have a virtual tour of the lava world for you all to play with!

Edge rows around your map would make displaying a *lot* easier since you don't need special logic for the edges, and provides sentinels that can make valid move checks easier as well. However, they chew up a *lot* of memory, which is something we don't have a lot of on the 99/4A. Plus, your border is locked to the size of the viewport, which means it is not very flexible.

 

The 2x2 tile collision detection can be a pain because you still want to move at single tile steps. Since you plan to use sprites to draw the main character, you might want to consider sticking to a single tile for movement and collision checks, and draw the 16x16 sprite centered on the single tile. It might look a little odd, but you don't know until you try. It might be fine though...

 

Matthew

[Opry99er]

Thanks Matthew. I'm really having a great time learning and problem solving. Mostly learning right now though. =) I think, if it won't slow it down too much, I might try to do a VMBR for the up and down motions, and then two single byte reads per horizontal direction. I don't mind doing the extra coding, but if you think it'll slow my code down too much, I might do as you suggest and figure out a way to do it with single tile detection. =)

[Opry99er]

Here's a short video of a virtual tour of the Forest World. It's donw in Extended BASIC, so it's pretty slow, but it's a neat video. This world map will have to be altered significantly in size and scope (just as the lava world was) to accomodate the 2x2 character. =) Anyway, without further adieu....

 

http://www.youtube.com/watch?v=4G0Mwy2z-r4

 

Hope you enjoy!!!

[Opry99er]

Currently I have a delay loop that DECs something like 6000 times before moving on--- just to make this video. Without that, it's insanely fast!!!!! I may have plenty of space for checks--- for instance, what happens when Beryl reaches a sapling? He certainly can't walk right over it... A "CI R1,sapling" needs to take place as well as a routine to tell the computer what to do once a sapling is touched. There will be many of these checks for different things on the screen. I hope I don't run out of the surplus of speed I have!!

[Tursi]

You will probably find you have quite a ways to go before you run out of performance --- and then we're all here to help you optimize.

[JamesD]

Currently I have a delay loop that DECs something like 6000 times before moving on--- just to make this video. Without that, it's insanely fast!!!!! I may have plenty of space for checks--- for instance, what happens when Beryl reaches a sapling? He certainly can't walk right over it... A "CI R1,sapling" needs to take place as well as a routine to tell the computer what to do once a sapling is touched. There will be many of these checks for different things on the screen. I hope I don't run out of the surplus of speed I have!!

You need to start using a display interrupt for timing.

[Opry99er]

Breakthrough this morning mentally. I can hybridize Matthew's method of single character checks with my 2x2 collision detection. I always want Beryl to be perfectly square

on the path he's on and I don't want any overhang and whatnot. So for path detection, I will use the same 2x2 method I have been working on.... However, enemy detection, item detection, etc can all be done using a single character as long as I'm clever with my map design. For instance, if I use the bottom right tile for detection, I must make sure there are no treasure chests touching a wall on the left. My character would stop before that tile gets to the treasure chest. If that doesn't make sense, I can do up a little graph paper example of how it works.... Of course, this is all just speculation right now--- I may have to do double tile checks for everything.

[Opry99er]

You will probably find you have quite a ways to go before you run out of performance --- and then we're all here to help you optimize.

 

thanks buddy!!! I need to figure out quite a bit of stuff still, but it's all starting to come together in the dude's ol' noggin here. . This scrolling world is far better than I thought it would be. So fast and so pretty. I am very glad I went with assembly on this one.

[Opry99er]

I made up 2 double sized SPRITEs and layered them. This is nothing special, but it gives me a starting point. =)

 

 

He doesn't look very "bad-ass" though, does he?

Edited May 31, 2010 by Opry99er

[Opry99er]

Here's the code for the Beryl Reichardt SPRITE layer I did above. Feel free to alter it, change it, whatever. I'd love some input here. Another thing I need to do is create a 2 pattern walking motion which (when displayed alternately) makes him look like he's walking. I need 2 SPRITE patterns for each direction, left-moving, right-moving, forward-moving, away-moving. If any of you would like to help in this endeavor, I'd much appreciate it!!!! =) Thanks, and please feel free to try this code out and modify if you'd like.

 

100 CALL CLEAR :: CALL MAGNIFY(3) :: CALL CHAR(96,"1F3F3F3F1F063F767F4F6FFF6F0D1D3D80C0C0C48E1FDFFFBF9F9F8E8480C0E0") :: CALL SCREEN(2)
105 CALL CHAR(100,"00051515050000003027FC273000000000004040040A111180E03EE084000000")
110 CALL SPRITE(#2,96,5,100,100,#1,100,15,100,100)
200 GOTO 200

[Opry99er]

Well I added edge characters. Every walkable space on the screen is now within "view" of real map characters. No more ASCII on the perimeters. This leaves me with a dilemma though. I cannot start the viewscreen draw at the beginning of the MAPDAT, because it's now taken up with lava and mountains. I have to start the draw in a different location. Therefore, I'll have to load MAPDAT into it's register and then AI the difference between the necesary starting location and the beginning of the map. Hope that works.

I'm now in the process of learning how to place SPRITEs on the screen. Also added the double yellow "viewscreen window" border. It's starting to look very much like a game. Too bad it's all just skeleton at this point.

[Opry99er]

New map is 63 rows high and a hundred columns wide. 6300 bytes. That's not a problem I don't think.... Anyone?

[+adamantyr]

New map is 63 rows high and a hundred columns wide. 6300 bytes. That's not a problem I don't think.... Anyone?

 

Well, considering you haven't written your engine yet, you should probably think conservatively. Also consider that you actually have a very small tile count for each map, which means using a whole byte per tile is a real waste.

 

However, compression has some complications. Namely, how to decompress only the section you need to see on screen? Run-length encoding doesn't work well with viewports; you'd have to decompress an unknown quantity of data before you get the section you want.

 

For a comparison, my own CRPG has a physical limit of 4096, or 4k for a map. That lets me have a map that's 64x64 tiles, 128x32 tiles, etc. Ultima II and III had maps of this size, but Ultima IV and V reduced it to 1024 bytes or 32x32 tiles, due to the increased tile count and the more complicated engine. The trick is that they only load what they need, and leave the rest on disk. The only complication is dynamic entities like monsters, they have to be tracked in a separate system of some kind so they won't just disappear when the player crosses a borderline.

 

From what I can see, you're envisioning each "world" as self-contained. I'd focus on what you need to do to keep that. I've messed around with dynamic section loading from disk, and it's difficult to optimize for a good experience. Every sector access costs time, and when it takes 2-5 seconds, your action game quickly bogs down.

 

On the subject of disk sectors, keep in mind two things:

- The TI disk sectors are 256 bytes long. You should keep your widths equal to a base 2 value, otherwise you're incurring unnecessary waste

- The maximum record width to fill up an entire sector is 128 bytes. The TI file system does NOT allow you to specify a record length of 256 bytes. You can cheat this by just accessing the DSR buffer in VDP directly (which has the entire sector) but some disk controllers may not buffer the sector in VDP, so it's not good to rely on that happening

 

Before you get too heavily into graphics and world and quest design, you should really make sure your engine is designed on paper. Assembly language is really hard to improvise in, and it's better to plan out what you want it to do. Write up a list of all the tasks you need the engine to accomplish (world loading, joystick movement, combat, text displays) and then check them off one by one as you experiment in assembly on how to get each one done.

 

Adamantyr

[sometimes99er]

Petite mise à jour

 

http://sometimes.99er.net/beryl.html

 

[Opry99er]

WOW!!!! That;s great man!!! How the hell do I use it?!? =) I find it DEVILISHLY ominious. The music is wicked!

[sometimes99er]

WOW!!!! That;s great man!!! How the hell do I use it?!? =) I find it DEVILISHLY ominious. The music is wicked!

Hehe, elementary my dear friend. Use the mouse. Draw with mouse down. Choose a color to draw with. Choose a background color. That's about it for now.

 

Music is Tenebrous Brothers Carnival, Act Three, royalty free. Supposed to stream automatically, but first time around you'll probably have it out of sync with the initial graphics. Just a bit of fun, though sound effects will be an option.

 

[Opry99er]

Before you get too heavily into graphics and world and quest design, you should really make sure your engine is designed on paper. Assembly language is really hard to improvise in, and it's better to plan out what you want it to do. Write up a list of all the tasks you need the engine to accomplish (world loading, joystick movement, combat, text displays) and then check them off one by one as you experiment in assembly on how to get each one done.

 

 

Thanks Adam! I've got the engine on paper. I've been thinking and working on the concept for quite a while now... From what you and Mark Wills and others told me, I have worked up a pretty good skeleton for what I want this thing to do and how I want to accomplish it. I don't know exactly how to do it all in assembly yet, but I'm workin on it. =)

 

And as you suggested, I want to keep each of these worlds totally separate from one another aside from variable passing. (stats, etc) My RPG will not be all that complex. It's going to be actually very simplistic. You walk around the map, collecting items and defeating enemies. Each world has a quest (like the 5 saplings in the lava world). Once the world quest is complete, you collect the key for the next world, and you defeat the boss for the level, you move on.

 

Exploration sequence will feel something like Mystic Quest on the SNES or maybe Shining 1. The larger enemies will be quite large, (2x2 tiles on the exploration screen) but there is a chance of you running into an enemy you didn't see. A simple stroke of the "M" key on your keyboard will pull up a menu that will look something like this:

 

STATUS

*Gives statistical status of each party member

ITEM

*Shows all items and allows you to use some of them on your party members when in menu mode (cure, elixir, etc)

SPELL

*Allows you to cast certain spells on your party members when in menu mode (heal, etc)

ARMOR

*Allows you to select the armor you wish to use for each character... of course it must be acquired as you go along

WEAPON

*Allows you to select the weapon you wish to use for each character... be sure to select your weapon of choice before you walk into an enemy on the map. I don't think I'll be allowing weapon switch during battle sequences.

 

 

Battle sequence will be much like the old Final Fantasy games on SNES . Turn based with chance for interrupts. Players stay put on the screen and you will have a menu for selecting your battling method. Menu items during battle are:

 

*Attack (a simple melee attack with whatever weapon your character has equipped at the time against whichever enemy you select)

*Item (pulls up "item" screen, from which you may select an item and who to use it on)

*Spell (pulls up "spell" screen, from which you may select a spell and who to use it on)

*Defend (you simply select which of the party members you want to defend on that turn)

*Run (umm.... fairly obvious)

 

So there really isn't much here... it's not anywhere near as richly detailed and complex as your RPG, man. I'm not at that skill level yet. =) Thanks alot for commenting here, Adam. I kind of look up to you and what you're doing with that RPG of yours. =)

Edited June 1, 2010 by Opry99er

[Opry99er]

WOW!!!! That;s great man!!! How the hell do I use it?!? =) I find it DEVILISHLY ominious. The music is wicked!

Hehe, elementary my dear friend. Use the mouse. Draw with mouse down. Choose a color to draw with. Choose a background color. That's about it for now.

 

Music is Tenebrous Brothers Carnival, Act Three, royalty free. Supposed to stream automatically, but first time around you'll probably have it out of sync with the initial graphics. Just a bit of fun, though sound effects will be an option.

 

 

 

I was quite pleased to see it there. =) What do you intend to do with it? SPRITE editor/layering tool? Something a bit like patterns, only way cooler because of the "Beryl Reichardt" theme of it? =) hehehe... Very cool, you using those old graphics of mine. I had forgotten about those ones.

[Opry99er]

Well, considering you haven't written your engine yet, you should probably think conservatively. Also consider that you actually have a very small tile count for each map, which means using a whole byte per tile is a real waste.

 

Graphics are VERY rudimentary at this point. I haven't even begun, really, to work on graphics. I've been most concerned with developing a bit of assembly source to get me started. The graphics will be much more detailed and I will be using quite a few individual tiles for each world. Remember that my initial intention was to do this in XB, so I had to keep everything as simple as possible and not much detail to the worlds. I'm coming over to assembly now, so my old constraints are right out the door.

 

I shaved about 200 bytes off the map size. Down to about 6000 bytes or close to it. =)

[sometimes99er]

I was quite pleased to see it there. =) What do you intend to do with it? SPRITE editor/layering tool? Something a bit like patterns, only way cooler because of the "Beryl Reichardt" theme of it? =) hehehe... Very cool, you using those old graphics of mine. I had forgotten about those ones.

Yup, sprite editor for 1, 2, 3 or 4 colors (obviously requiring 1, 2, 3 or 4 sprites respectively).

 

Some ideas are ...

* Warning about more than 4 colors

* Assembler output

* The usual clear, rotate, mirror, flip, move/scroll and double

* Fill

* Undo and redo

* Stacked sprites (16x32)

* Animation

* Save and load

 

[Opry99er]

These SPRITEs are kickin my aZZ!!!!! Ugh, I never thought it would be so complicated to put a SPRITE on the screen. Thank God I'm not MOVING them! =) On Sometimes's suggestion, I fixed one value in my descriptor table, but now I cannot get the second SPRITE to display at all. This is just one little frustration.... I'm not going to let it bother me... breathe in, breathe out, breathe in, breathe out.......

 

(...............stupid SPRITEs)

 

 

=)

[Opry99er]

So--- here are my next couple steps, I think, once I get my character on screen, in bounds, and moving.

 

-Finish "exploration screen"

*Add all the stats, character info, etc to the screen.

-Create necessary collision checks with the saplings

-Create "Menu" screen and code in the KSCAN to check for it.

-Complete and implement the directional Beryl representations (travelling right, left, etc)

 

 

If I can at least get that much done for now, I'll be pleased. Then it gets a little tougher.

[matthew180]

I think you need to kill the borders and go for keeping the map inside the view port. The edges take up way more data than they are worth, and it also locks you into a max view port size.

 

I'll have an example for you soon, also with sprites. :-)

 

In the mean time, the key to sprites is the sprite attribute table (SAT). Four bytes are all you need to worry about. You use two VDP registers to set the SAT location and the sprite pattern generator table (SPGT) location (which can overlap the tile PGT if you want to use the same pattern memory for both sprites and tiles.)

 

See the GMODE subroutine in my examples over in the assembly thread.

 

Matthew

[Opry99er]

Thanks alot buddy! I'll be busy as hell for two weeks playing 2 4 hour shows a day down here in Key West. I'll try to get some stuff accomplished anyway.

[JamesD]

The lava levels need some characters that are animated in the lava to make it look like its bubbling.