The Legend of Beryl Reichardt

[Opry99er]

 

. Good, not great

[UnderExtended]

. Good, not great

 

I like it (see my earlier reply, which I edited before I saw your latest post). I also like your lava levels a lot -- they look better each time you post an updated one.

 

Also, Codex's graphic "berylsprites.png" is excellent. And by having Beryl facing toward the player, you save the space of not having to have graphics of him facing left and facing right. Only 3 frames needed: 2 for the walking, and 1 for attack maybe. That's something to keep in mind with the enemy design too.

 

I gotta run soon. I tried to send you my email address through Atari Age, so just send me a reply if you got it. I looked for your address at your site, but didn't find it.

 

--Rich

[Opry99er]

I will actually be using 16 tiles or 2 character sets to make up Beryl's graphics. 4 tiles of graphics per direction.

 

and I will be getting creative on the layered SPRITE(s) which will make up the second color of Beryl's design

Edited May 27, 2010 by Opry99er

[Opry99er]

So I have a series of questions that I need to get answered... First, must all screev positions be written as words? By this I mean, i need ri check a single byte on the screen, let's say 2nd row, 3rd column. This screen position would be >24. Now, since the screen position is under 255 or >FF, could I simply check for >24, or should I check for >2400, where the MSB is >24? Mane more points and questions forthcoming--- I'm driving through southern Georgia on my way to the Keys and I need to focus on driving. . But my mind works best while I'm driving, so I'm gaving some great TI reflection time right now.

[Opry99er]

Okay--- I'm starting to see that certain elements of my game will be driven by/triggered from the KSCAN user input and some will be independant of the user input. For instance, the motion of the water in the Forest World and rhe motion of rack of my enemies on screen will be taking place whether Beryl is "in motion" or not. I imagine that these elements will be hooked into the ISR (or some equivalent thereof)

 

On user input, the following things need to happen in this order. I think.

 

Let's say the player moves left by using the joystick.

 

-change hero pattern to "left-facing"

-check the 2 screen positions immediately to the left of my double sized SPRITE... (this is easy because since Beryl is always stationary, the screen-check for legal motion will always be the same two posioions)

-If move is legal, scroll the map one character left--- thereby decreasing the map data location for each tile in the window by 1.

-go back to KSCAN routine.

 

Hope this makes sense... Please correct me if I'm wrong before I spend hours tomorrow trying to make this thing work.

[sometimes99er]

So I have a series of questions that I need to get answered... First, must all screev positions be written as words? By this I mean, i need ri check a single byte on the screen, let's say 2nd row, 3rd column. This screen position would be >24. Now, since the screen position is under 255 or >FF, could I simply check for >24, or should I check for >2400, where the MSB is >24? Mane more points and questions forthcoming--- I'm driving through southern Georgia on my way to the Keys and I need to focus on driving. . But my mind works best while I'm driving, so I'm gaving some great TI reflection time right now.

When you read VDP memory you set the VDP address with 2 bytes always as explained by Matthew. So using a subroutine you have to set R1 with the value of >0024. You can set it like this

 

LI R1,>24

 

R1 will then effectively become >0024. There are other ways, but generally you're not saving anything while in the upper part of the screen (>0000 - >00FF). Assuming the screen is located at >0000 (>0000 - >02FF).

 

[sometimes99er]

This is just a very quick Flash mockup on the multi color sprite talk. It doesn't do much and there's probably a few bugs. You can paint and change colors, but that's it.

 

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

 

As with Patterns you can have a resizable "version", but then it's not all pixel perfect.

 

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

 

The swf size is 2328 bytes. I'm using more direct approaches within Flash, and was surprised to find CPU usage to be 0% in all cores. I guess GPU usage is also quite minimal. Anyone know how to read this in Windows 7 ?

 

If you have any ideas, requirements, comments on text, design, effects and/or bugs to report don't hesitate to mail me privately. We wouldn't wanna hijack this thread. I'll be away most of this weekend, so take your time.

 

[Opry99er]

Thanks Karsten!!! Was hoping to see something like this! . Look forward to trying it out this weekend!!!

 

Question... Well, kind of a question, sort of a statement. Assuming my overall world map is 80 tiles in width and 45 tiles high. The way I understand the "viewscreen parsing" is this. Each row is offset to the other row by 80. The top row is

 

0,1,2,3,4,5,6,7,8,9,10,......

 

The second row is

 

80,81,82,83,84,85,86,87,88,89,90....

 

So if I wanted a 10x10 window, I would need to define the top left position as something by which I would offset the rest of the window. We know that if the top left character is known as VIEWSTART1, and the character below VIEWSTART1 is VIEWSTART2, then we know that VIEWSTART2=VIEWSTART1+80. With that offset, we have all the starting positions we need for the VMBW routine (or equivalent) and the length will always be 10, and the process would repeat 10 times, with VIEWSTART increasing by 80 each time. Is this accurate?

Edited May 27, 2010 by Opry99er

[sometimes99er]

Yup, that's about right. Now you have to decide whether Beryl will be able to travel the outer rims of the map territory or not. Would he then still be fixed in centre. And would the map then wraparound or would undefined areas be as black as deep space or something.

 

 

Edited May 27, 2010 by sometimes99er

[Opry99er]

Coool!! Hey man, I wouldn't have to loop code 10 times to draw that window, right? I could come up with something-- maybe define each line with the EQU directive (offset by 80 from the previous line) and then just redefine VIEWSTART1 after each move.... Yea?

[sometimes99er]

Coool!! Hey man, I wouldn't have to loop code 10 times to draw that window, right? I could come up with something-- maybe define each line with the EQU directive (offset by 80 from the previous line) and then just redefine VIEWSTART1 after each move.... Yea?

You will need to loop.

 

You'll be moving one byte to the VDP at a time. So you have to have two loops. One dealing with horizontal distribution , and one outer loop dealing with the lines. If your window is 15x15 you know you would have something like this

 

100 FOR row = 0 to 14

110 set VDP address to point to row*32

120 FOR column = 0 to 14

130 write data to VDP (address auto increase)

140 NEXT column

150 NEXT row

 

[sometimes99er]

Let me draw you this picture then. What happens on the screen if Beryl tries to move to the edge of the map ? Knowing that Beryl is fixed in the center of the screen.

 

 

[Opry99er]

Good question. Perhaps I will extend the map a bit to always make sure there won't be an instance of that occuring. . Add mountain ranges or something impassible to keep the viewing window away from the edge of the map.

[The Codex]

For viewport rendering as in Beryl I always go for the easy-out. I maintain two variables - OffsetX and OffsetY - which are the upper left corner of the where the visible map chunk begins. Every time the player moves I update the offsets with this rule:

 

OffsetX = PlayerX - (ViewportWidth / 2)
OffsetY = PlayerY - (ViewportHeight / 2)
IF (OffsetX < 0) THEN OffsetX = 0
IF (OffsetY < 0) THEN OffsetY = 0
IF (OffsetX > (MapWidth - ViewportWidth)) THEN OffsetX = (MapWidth - ViewportWidth)
IF (OffsetX > (MapHeight - ViewportHeight)) THEN OffsetX = (MapHeight - ViewportHeight)

 

Then I just draw the map chunk in the viewport using my offsets as the start points:

 

FOR Y = 0 TO ViewportHeight
FOR X = 0 TO ViewportWidth
DRAW MAP[OffsetY + Y][OffsetX + X] AT VIEWPORT[Y][X]
NEXT X
NEXT Y

 

Obviously this is pseudocode, but you get the idea.

Edited May 27, 2010 by The Codex

[Opry99er]

Thanks man... I had something similar

to that in mind, but it may not have been quite as clear and simple as that. In assembly, the pseudocode would be something like this--- and I didn't have help, so I'm sure it's wrong. But I think I know the problem, it's the AI 70,R1... That doesn't feel right.

 

DEF START
REF VMBW

START
    LI     R5, 10 *loop count     
    LI     R0,35 *starting screen position
    LI     R1,MAPDAT will load info from the MAPDAT labeled data table
    LI     R2,10 *length of print 
DRAW   BLWP@VMBW *draw it!
    AI     R1,70*carriage return in map data
    AI    R0,32 *carriage return on screen
    DEC   R5 *decrease loop count
    JNE   DRAW *if not zero, jump back to "DRAW"

MAPDAT DATA >....,>...
.
.
.
END

 

It's probably non functional, but the concept is there i think.

 

 

Again, I'm just guessing for the most part...

Edited May 27, 2010 by Opry99er

[Opry99er]

Took a few revisions, but I think I'm

pretty close now.

[+adamantyr]

Good question. Perhaps I will extend the map a bit to always make sure there won't be an instance of that occuring. . Add mountain ranges or something impassible to keep the viewing window away from the edge of the map.

 

I did two techniques for that in my CRPG: wrapping or repeat. It's a flag value in the map header to determine which to use.

 

For repeat, if a given position is out of bounds, it uses the closest position and just replicates that position. This causes a "stretch" effect both horizontally and vertically. You do need to make sure your corner-post tiles are something that is repeatable in a whole quadrant, though. A variation of this is to just repeat a single tile type.

 

For wrapping, I just add a displacement value to an out of bounds value to make it back on the map. This means the map "wraps" around. This is useful for maps that I want to do mazes on, and also lets me construct maps on square design that actually seem bigger and less square than they are. The only downside is I know that it's doing more cycles to calculate a wrapped tile than a natural one... the current engine seems to work okay for the scale I have, but I may have to figure out a way to optimize it eventually.

 

Adamantyr

[Opry99er]

Good advice Adam, thank you!!!

[Opry99er]

DEF START
REF VMBW

START
    LI     R5, 10 *loop count     
    LI     R0,35 *starting screen position
    LI     R1,MAPDAT will load info from the MAPDAT labeled data table
    LI      R2,10 *length of print 
DRAW   BLWP@VMBW *draw it!
    AI     R1,70*carriage return in map data
    AI    R0,32 *carriage return on screen
    DEC   R5 *decrease loop count
    JNE   DRAW *if not zero, jump back to "DRAW"

MAPDAT DATA >....,>...
.
.
.
END

 

now, if we wanted to create motion, we can take a KSCAN read which would help us determine the intent of the user. If the user moves the joystick left, we would simply

 

DEC R1

and draw again. It should move the top left tile to the left one space, thereby also manipulating all the rest of the viewscreen data to the left, one tile...

Edited May 27, 2010 by Opry99er

[+adamantyr]

DEF START
REF VMBW

START
    LI     R5, 10 *loop count     
    LI     R0,35 *starting screen position
    LI     R1,MAPDAT will load info from the MAPDAT labeled data table
    LI      R2,10 *length of print 
DRAW   BLWP@VMBW *draw it!
    AI     R1,70*carriage return in map data
    AI    R0,32 *carriage return on screen
    DEC   R5 *decrease loop count
    JNE   DRAW *if not zero, jump back to "DRAW"

MAPDAT DATA >....,>...
.
.
.
END

 

now, if we wanted to create motion, we can take a KSCAN read which would help us determine the intent of the user. If the user moves the joystick left, we would simply

 

DEC R1

and draw again. It should move the top left tile to the left one space, thereby also manipulating all the rest of the viewscreen data to the left, one tile...

 

That should work fine. Code it up and try it out!

 

For any operation where you interrupt the VDP write with an address change, and are doing visible display, it's a VERY good idea to just hit the ports directly rather than use the VDP utilities, even if they are BL and using the scratchpad workspace area.

 

You could also write to a buffer screen in VDP and then swap the visible screen with a single write to the VDP register. That means the transition is clean, and the only noticeable problem may be a bit of a drag between movement if you have too much going on. Also with buffers, unless you have static page elements you built prior, you'll have to update everything on every pass on the off screen, like items, health values, etc. For my CRPG, I use a status word value to track what kind of refresh is needed so I can only update what's absolutely necessary on a given pass.

 

Keep in mind that in assembly language, you're no longer constrained to do your dirty laundry on the screen itself. For example, you wouldn't place enemy characters and items using VCHAR, instead you would pre-process the map data to include every visible element and just write it out to screen. Sprites are an exception to this; any movement of them is updated directly, and they don't respect buffer boundaries, so if they need to disappear from view you'll have to disable them. (Which is easy, you set the first sprite's Y position to >D0 and it will stop displaying ALL sprites.)

 

Adamantyr

[sometimes99er]

Sprites are an exception to this;

Sure ? You could double buffer the sprite attribute list. Even the sprite descriptor table could be double buffered or used for quick animation of many or all sprites.

 

[Opry99er]

To make my player "stay in bounds," I would simply need to check the same 2 screen tiles for each direction. If my Beryl SPRITE sits fixed at screen locations 310,342,311,343--- then if the player selects "left" (to keep with the theme) we need to do a read of screen positions 309 and 341 to check legality of move. If the player moves "up", we need to check 278,279. Am I on the right track with this stuff?

[Opry99er]

Thanks for the feedback and info guys.

[sometimes99er]

To make my player "stay in bounds," I would simply need to check the same 2 screen tiles for each direction. If my Beryl SPRITE sits fixed at screen locations 310,342,311,343--- then if the player selects "left" (to keep with the theme) we need to do a read of screen positions 309 and 341 to check legality of move. If the player moves "up", we need to check 278,279. Am I on the right track with this stuff?

Yep.

 

Have you considered diagonal moves (like down and right at the same time) ?

 

[Opry99er]

Well, I've done it... For the most part anyway. . I need to figure out how to color and define my characters and screen... Kinda hung on that. I have all the nice exported code from Magellan, but don't know how to make it happen. I'm doing some reading now--- I'll post the EA3 file when I get closer.