Jump to content
IGNORED

Assembly->XB link project


Opry99er

Recommended Posts

When I finished my original scroller, I was encouraged... When I ran Matthew's scroller, I was amazed... I wanted to use his scroller and work with it.... Build the game around his code.... But I just couldn't figure out what I wanted to do...it was like trying to add to the Mona Lisa... How do you add to that!?!

Link to comment
Share on other sites

I'll be making some significant changes to this process tonight... I've decided on a viewport and a map size... I should be able to create an interesting world using the tiles I have for the Forest world... even with the XB charset limitations...

 

One question first... What would you guys do to track the following:

 

1) What "screen" (out of 6) am I on?

2) When the character moves off that map, how would you track what "screen" is to be loaded next? (depending on up, down, left, or right)

 

I had thought about setting up something like an array,

 

DIM MAP(3,2) where MAP(1,1) would be the top left section, MAP(1,2) would be the second section, directly below MAP(1,1), MAP(1,3) would be directly below that--- on the bottom left of the overall map. MAP(2,1) is the top left section, MAP(2,2) would be the section below that, and MAP(2,3) would be the bottom right section of the screen.


*---*---*
*1,1*2,1*
*---*---*
*1,2*2,2*
*---*---*
*1,3*2,3*
*---*---*

 

That's the look of it. =)

 

Thanks... I welcome input.

Link to comment
Share on other sites

I've attached the .mag file that is 58 characters wide (the big map) giving me an even two screens wide (excluding the spaces and the border). Please enjoy, and if anyone wants to make some changes to the landscape... this is just mockup at this point, so I'm hoping to find someone to contribute graphically to this world. =)

Forest3.zip

Link to comment
Share on other sites

Very well. You have chosen 12 high and 28 wide.

 

I'll try to get back to some of your questions etc. at some point. Otherwise just ask again.

 

12 x 28 = 336 bytes (one viewport)

 

We assume 4K at our disposal. K = 1,024. I'm sure we have more, but let's play it safe.

 

4 x 1,024 / 336 = 12,19...

 

We will then have 12 viewports available in memory at the same time.

 

We could arrange things like 2600 Adventure, but to make it simple for us as both graphic designers and programmers, we will go for one big rectangular map (one world). That's viewports arranged/distributed nicely in one big map. 12 viewports leave us a good deal of possibilities. This is no. of viewports high and wide:

 

12 x 1

6 x 2

4 x 3

3 x 4

2 x 6

1 x 12

 

You have to choose one now.

 

:)

Link to comment
Share on other sites

Well, I assume it will be possible to use a different configuration of maps for each level?

 

(Forest Level, Desert Level, Mountain Level, Cave Level, Lava Level, Dungeon Level, Underworld)

 

=) For the Forest world (my first world of focus), I will go with a forest world map that is 6x viewports high by 2x viewports wide. This would leave me with a large map of

 

6x12=72 tiles high

2x28=56 tiles wide

 

need tomake some adjustments and try to get the most i can get out of my limited charsets. =)

Link to comment
Share on other sites

Here's how I'm thinking here.... I want to write a "lite" version of Beryl Reichardt in XB with assembly support while I continue to learn and progress in TMS9900 assembly language. I think this XB-->assembly linkup project is a good way to get familiar with how I want to handle variables in the game and construct gameplay. Of course I am limiting myself in speed and character sets, but this will help while I slowly progress in assembly. The ULTIMATE goal is to do a final Beryl Reichardt in assembly--- using full scrolling (Matthew's scroller is wicked) and all available character sets. As to not lose Beryl to the darkness of vaporware, this project will move forward now...

 

Think about Legends on a larger scale with music. More action, less frequent random battles, strong storyline and NPC interaction. With the tools I'm writing right now and the few small successes I've had linking XB and assembly, I feel confident going forward. I have 10-15 pages of Beryl Reichardt documentation that I've written including enemies, NPCs, towns, worlds, magics, etc. These documents are sitting unused because I decided to do Beryl in assembly and have no idea what the hell I'm doing in assembly. I should have stuck with XB with AL support routines... I would be much further along by now.

 

So, in conclusion... I'm going to be re-organizing the documentation and preparing myself for total immersion into this world. Keep up with the progress here... I may change the title of the thread... as I don't believe this forum needs another "Beryl" thread.... there's already one big one and then the Berylrogue thread... I've made good progress in bits and pieces, but I'll be consolidating it all into one big development document which will outline everything I plan to do, and I will post it here soon.

 

Special thanks to Matthew, Codex, sometimes99er, and Adamantyr for your inspiration and patience. This is gonna be fun. We WILL have this done by the Faire... if not, shoot me with a bow and arrow and call me a cave-dweller. =)

Link to comment
Share on other sites

Well, I assume it will be possible to use a different configuration of maps for each level?

Yes.

 

For the Forest world (my first world of focus), I will go with a forest world map that is 6x viewports high by 2x viewports wide. This would leave me with a large map of

 

6x12=72 tiles high

2x28=56 tiles wide

Yes. You got it. ;)

 

need tomake some adjustments and try to get the most i can get out of my limited charsets. =)

All character definitions and the big map can be changed/updated by you from now on as many times as you wish. Only limitation for now is, that the big map will have to stay 72 characters high and 56 characters wide.

Link to comment
Share on other sites

I'm also thinking I will have a different XB program for each of the worlds with it's own set of charsets and whatnot. Also, when it's "Battle time", I will need to load some new character sets for monsters and player SPRITEs, and then simply switch back when I go back into exploration mode. I had planned to handle all charsets in XB, but switching back and forth might be slow.... I'll run some tests to see. I may end up doing character definitions in assembly, but I think it will be okay if I'm just modifying 4 sets each time. I'm writing a big blog-type write up on this just to get all my thoughts in one place. :)

Link to comment
Share on other sites

Ahhh,sometimes... I missed your post since we were posting at the same exact time. =) I'll have a magellan file for you very shortly. About to eat dinner, and then I'll get it worked up. =) I've already set the new sizes of the map, just need to populate the blank sections with mazes and such. This will be all preliminary, and (as you say) will more than likely be changed as we move forward. I have had some graphical inspiration today by playing a bit of "Legends" and spend about a half hour playing "Ultima IV". =) Thanks for your support, buddy.

Link to comment
Share on other sites

I've changed my mind about the font, however..... =) Watch until about 25 seconds in... This font is great and it sucks all at once. =)

Oh, so you were going to used that Faxanadu font with Beryl ? Cause you can't use it with Beryl Light, map only would maybe be doable, but with a battle screen like that, I don't think there's hope for lowercase. Other than that, if you correct the capital H (move one pixel), then I don't think the font is any worse than so many other 8x8 pixel fonts.

Link to comment
Share on other sites

0030beryl.png

 

Excellent, map 11 in your project file has the right size.

 

Now what I did was to place character code 33 (exclamation mark appears black on black, but the code should appear in the map data) in each of the 4 corners of the map (big). I'm doing this to be able to look at the exported data, and confirm that everything, or at least size, is alright.

 

I exported to "XB Program" and "Assembler Data" - selecting the "Current Map Only" option with both of them (also wanted "Include Comments", but that's already selected). Yes, I created 2 files. The assembler output is easier to check. The XB output has those DATA lines with 16 values, but I found my character code 33 at exactly the expected positions. You should try this out too.

 

I think we will use the "Assembler Data" output. We might use "Binary Data" output at some later stage.

 

Now, we will go and do some assembler coding ...

Link to comment
Share on other sites

Owen, it's your project, your game, your code - and you're pretty much screwed.

 

What I will try and do is this. My posts will be short (apparently not). I will avoid commenting too much on your "detours" or "jumping ahead". It's more than alright for you to have thoughts about this and that. It happens when you have a creative mind. But I think for you to learn, understand and use assembler, I'll lead you gently (NOT!) on a simple step by step approach. I'll lead you "my way", much as I see fit. I do however welcome input from others. We'll simply go along and see what happens. Also I'll try and make sure, that you are with me (checkpoints). At some point it might all get out of my hand for whatever reason(s). I will try and be polite and say when and why. Phew ! And please don't shoot me.

 

What we want to do now is take the top line of the big map. Just the first 28 bytes (width of the viewport) and display them in the top left corner of the screen. We don't care about the offset for now. I need for you to do a simple XB program and assembler program to do this. I'd prefer a zip with 2 text files. I need your best shot and it doesn't have to compile or anything. If you were sitting in front of me, you'd have about 20 minutes on your own - starting ... Now !

 

;)

Link to comment
Share on other sites

I'm in bed right now. :). In 6 hours I will arise and write something wicked awesome good. ;). I may even be able to display the whole damn viewport. :)

 

I appreciate your help-- and I am fully prepared to do every necessary step to get where I need to go. For the here and now, I have the routine in my mind and the steps by which I will accomplish the task at hand. I'll write something in the morning that will assemble and will hopefully surprise myself. :)

 

Thanks to a few awesome contributors here, I think I'm closer and closer every day to having a viable project--- so far I've completed two games in my programming journey.... Since that second one, I have waffled around the concepts of the RPG and XB vs. Assembly.... I'm just going to go full steam on this project now. No distractions. Except sleep. :). Goodnight.

Link to comment
Share on other sites

Okay, My program assembled (thank God) and it linked up to the XB program. However, the results onscreen don't quite look right.... I've attached the two textfiles to this post. Here's a pic of the jumbled mess onscreen.

messforest.png

 

 

The data listed in my source code (SOMFOR.TXT) shows the first several bytes are all the same... but obviously the display doesn't agree. =)

XBFOREST.zip

Link to comment
Share on other sites

Okay, got your source files. Your code looks fine.

 

I fixed the END and indentation in the assembler file. Compiled fine and program runs. Apparently, apart from the lack of a CALL SCREEN(2), there is a problem. Magellan on top of my Classic99 output. Do you get the same ?

 

0031beryl.png

 

Debugging does however not only involve Magellan output, XB and Assembler, but also a "black box" to me - your converter. I was actually trying to avoid that one. I had hoped you would use Magellan "Assembler Data" output, and not care about the offset.

 

When I compare the Classic99 output with your converted data, there's a match. The first 28 bytes cut from your source:

 

MAPDAT	
BYTE 233,233,233,233,233,233,233,233
BYTE 233,233,233,233,233,233,233,233
BYTE 233,233,233,233,233,233,233,233
BYTE 233,210,233,210

 

So my dear friend, the bug is in your conversion - or could it be yet another cut and paste bitch ? You can now choose to either fix or ditch your converter.

Link to comment
Share on other sites

Well if I can simply use the assembly data from the Magellan output without offsetting anything, that would be great! I thought both the assembler output and the XB would have to be shifted. >20 and 32 are the same, so why would >20 work and not "32"?

 

If that is the case--- that I don't need to shift the assembler output, then that's what I will do. I only wrote the converter program because I was under the impression that when linking assembly and XB that the data had to be shifted regardless....

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...