The Legend of Beryl Reichardt

[The Codex]

Agreed snume. Too many remakes are just pallid attempts to capitalise on the love of the originals without staying true to their style and content. I actually love everything about the Shining Force games and would like another one of those, not one that's been morphed into 3D combat or with FMV cutscenes or whatever. If people want to do that, they should just start their own franchise.

[Opry99er]

Well, I hope to make Beryl a staple... When my game is done, perhaps in the future I will write one in DarkBASIC... A slick modern BASIC that taps into ActiveX engines!!! There's already a badass prequel to my game... Way before mine is even in a playable demo form. I'm a tool.

[Opry99er]

Thinking of writing two games at once to coincide with one another... Beryl, and Berylrogue. Screenshot below

 

 

[sometimes99er]

Beryl, and Berylrogue.

Hehe. Great !

[Opry99er]

<<<pasted from Roguelike? thread>>

 

XB Mockup of Beryl Reichardt "Roguelike edition". I did this in Magellan and then used the LOADMAP sub to create a datafile and the DRAWMAP routine to do it up in Classic99, and here's the pic. Hope you like it... if there's interest, I'll continue to build the concept and post some demos here.

[Opry99er]

Karsten--- you play many Roguelikes?

[Opry99er]

Little program to show ya here... This was fun to put together!!! Do this, in Classic99, change your DSK1 to @DSK1 just to move it out of the way temporarily. Unzip this file, drop DSK1 into your Classic99 main directory and select XB.... Will autoload. Hope you enjoy it!!! =) Thanks to Howard Kistler for his development of Magellan.

 

This is a runthrough of the 6 gamescreens in the Forest World of "Legend of Beryl Reichardt". Having fun now... =)

DSK1.zip

[Opry99er]

Okay--- there is a way to have scrolling and music all at once. Here are the principles:

 

1) Map data: The new map for the Forest World will be 60 rows and 75 columns. These are the dimensions of the data. 4.5k.... The data can be thought of similarly to how the VDP designates a screen position... In AL, there aren't X and/or Y coordinates on the screen--- the screen positions are numbered in a linear fashion from left to right and top to bottom, leaving a total of 768 possible screen positions. Think of our 60x75 map in the same way. (BTW, what is the proper designation of this grid?? 60x75 or 75x60?) More on this in a minute.

 

2) Scrolling routine: the scrolling routine will do nothing more than read the requested bytes of data from the map data we saved. Here's how it works... For the sake of simplicity, let's say we have a 100x100 grid and we want to scroll inside of a 10x10 window. (which is what Beryl do, but with a 15x15 window). If you think of our map data as a piece of graph paper 100x100 in dimension. Let's say we have a 10x10 square that will move one space at a time in either of the 4 directions. Now let's say we place that square on the top left of the larger 100x100 map. The "first" character, or top-left, will be indicated by a 1, the position to the right of "1" will be "2" and so forth. So, what does our window contain? The top left is a "1", and the bottom right is "1010".... So, on that note, if you "scroll" or move your window one space to the right, the top left position becomes a "2" and the bottom right becomes a "1011". Make sense?

 

So, since we can see that the difference in map data between any two positions in our window will always remain the same, it makes sense that a clever equation along with a VDP utility such as VSBW or

VMBW would be able to do the deed. With this, we can get a super fast scroll, albeit a 1 character at a time scroll. So, I'm learning with help from Marc and Matthew and Mark. The M&M&M boys. Anyway, if it helps to conceptualise, think of our scroll routine as a magnifying glass passing over a manuscript. And each letter, number, space, and punctuation mark on the page, starting at the top left of the screen and counting by "1" until the page ends. Our magnifying glass can read 225 characters at a time in Beryl, but not consecutive numbers--- they're in strings of 15 characters, fifteen rows deep. Hope this makes sense.

Edited May 5, 2010 by Opry99er

[Opry99er]

 

Hope this helps. Just a stupid little mockup.

[Opry99er]

*** ***

* * * *

* * * *

* *** *

* *** *

* * * *

* * * *

*** *** ELLO

 

This is a test to see how ASCII graphics look in this forum... got some ideas. =)

 

 

<<edit>>

 

They look pretty crappy

Edited May 5, 2010 by Opry99er

[Opry99er]

Then again-- It has been pointed out to me just recently that a scroll routine might have to disable the interrupts... So, in that case, I might have to think about doing entire screen draws instead of scrolling. I don't know yet, as I'm just learning and studying as I go....

 

SOOOOOO----

 

Assuming I end up going with the screen by screen draw, i will have to write an XB routine to check for my character's relative position to the map's edge.  For instance--- if you've ever looked closely at my maps, you cannot reach the next screen except by paths and occasionally a "grass" character.  The path and grass character are the only passable characters in this world--- so if the player is at the right side of screen 1, and the "space" character which separates the map from the border is within one character position of the play piece, then the player is at the edge of the map.  To do a series of XB checks will eat up speed--- this doesn't seem to be too bad though.... 

 

* REM SPRITE #1 (the play piece) 

* WILL MOVE BY A FACTOR OF 8, 

* ESSENTIALLY ONE SCREEN 

* POSITION AT A TIME, NO AUTO MOTION

 

500 CALL POSITION(#1,YPOS,XPOS)

510 CALL GCHAR(INT(YPOS/8),INT(XPOS/8),SC)

520 IF SC=32 THEN GOSUB 1000

.

.

.

1000 REM CHECK FOR WHICH NEW SCREEN NEEDS TO BE DRAWN

1010 ASSEMBLY SCREEN DRAW

 

So, if we have 6 total screens, at around 600 bytes per screen rather than 768 (leaving out the space characters outside the actual map area we are drawing and at the top of the screen) we're talking under 4k low memory for map data... That could be loaded into memory and each screen could be LINKed at the necessary time....   

[Opry99er]

Thanks Marc.

[sometimes99er]

Karsten--- you play many Roguelikes?

No, not at all. I like a bit of 8-bit color graphics (or more). But I support the idea, and would most definitely play any new TI incarnation.

 

[sometimes99er]

This is a test to see how ASCII graphics look in this forum... got some ideas. =)

 

<<edit>>

 

They look pretty crappy

Use the "insert code snippet" icon and design between the tags (code and /code).

 

   ,----..                                      
  /   /   \                                     
 /   .     :                                    
.   /   ;.  \        .---.               ,---,  
.   ;   /  ` ;       /. ./|           ,-+-. /  | 
;   |  ; \ ; |    .-'-. ' |   ,---.  ,--.'|'   | 
|   :  | ; | '   /___/ \: |  /     \|   |  ,"' | 
.   |  ' ' ' :.-'.. '   ' . /    /  |   | /  | | 
'   ;  \; /  /___/ \:     '.    ' / |   | |  | | 
\   \  ',  /.   \  ' .\   '   ;   /|   | |  |/  
 ;   :    /  \   \   ' \ |'   |  / |   | |--'   
  \   \ .'    \   \  |--" |   :    |   |/       
   `---`       \   \ |     \   \  /'---'        
                '---"       `----'        

 

[matthew180]

Hey Owen,

 

"Technically" 60x75 is 4500 bytes, which is 4.394K (one "K" is 1024 bytes). Anyway, you want a 60x75 map then... Hmm. I'll have to go back and look at the post where I worked out how much RAM you have available in the low memory.

 

Having a 15x15 "viewport" over the map is no problem really and increases the feasibility of pulling it off during the console ISR. There is no reason to redraw the whole screen.

 

So I assume your map data is simply the character value to display, right? Let me see what I can come up with.

 

Matthew

[The Codex]

"Technically" 60x75 is 4500 bytes, which is 4.394K (one "K" is 1024 bytes).

 

"Technically" a fist to the face is four fingers and one thumb, but since I'm curling my pinky under then this shouldn't hurt you like a "real" fist to the face would.

 

Seriously, looking forward to your viewport solution. I can see a lot of utility value in routines like that, since I often create games with a control interface surrounding the play area.

[Opry99er]

Damn, Sometimes!!! That looks awesome! Hahaha!!!

 

Thanks for the info Matthew. . I will be working on this assembly support all this week.

 

I have decided to write the "Berylrogue" game in 100% assembly. Marc, Mark, and Matthew have been very helpful to me, and I believe I can do it. Shouldn't be too difficult to write it... Especially since I now understand that symbolic memory addresses don't have to be defined!!! I don't even have to know where the hell my data is going as long as it has a label. I am as giddy as a schoolgirl.... wait..... That isn't the image I'm trying to portray

[Opry99er]

Well, I have decided to work on "Berylrogue" in TMS9900 assembly while I continue conceptual development on "LoBR". While I get acquainted with developing my arrays and map draw functions in Beryl, I will be applying those same principles in the TMS9900 development environment with "BerylRogue." wish me luck and keep in mind--- The Berylrogue thread will essentially be a tutorial on assembly language--- as I am learning from scratch, essentially. I will continue work on my LoBR game as I press on with Berylrogue. Hopefully, when Berylrogue is done, I will be able to use the same routines to do this one in assembly too. Keep an eye out for the Berylrogue thread which should be hitting the forum later today.

[Opry99er]

Notice the "exploration" sequences. LOVE this design. Also, the battle sequences... No user movement forward or backwards, side to side, it's a static battle position. The battle sequences will be menu driven. I'll be doin' some work here on this game... Hope to have some movement routines done soon so you can walk the levels. I'll release that as a demo first... you'll be able to walk from the beginning, all the way through the levels, pick up items, and exit through the mountain passage. =) If I had an hour to code... just one uninterrupted hour..... Ahhhh

http://www.youtube.com/watch?v=E1MCLMRKklQ

[Opry99er]

 

Trivia.... what game, what platform. =)

[+adamantyr]

 

Trivia.... what game, what platform. =)

 

Game: Final Fantasy (One, Prime, the Original, etc.)

Platform: MSX2, Famicom, Nintendo Entertainment System

[Opry99er]

You're pretty fast, Adamantyr.... I believe I shall let you live.... As for the rest of you.... SHAME!!!

[The Codex]

Bah, I refuse to acknowledge any series called Final Fantasy that contains more than one game.

[Opry99er]

Hahaha!!! Kinda like the first

time I heard "The Final Countdown.". I seriously rejoiced that it was the last "Countdown" I ever had to hear... Then it was on MTV again the next day. I felt truly jipped. And Final Destination??? Bah!!!!

[Opry99er]

Today I learn how to do colors and character redefinitions in assembly. Imagine the awesomeness of assembly drawing the Forest World. I smell a video coming on!!!