748 replies to this topic

[Opry99er]

I changed the width to >8357 because the new map width is 87 instead of 84 as before.... The heights is curious to me though, because I don't think the map was 86 characters high... of course, that matters less than the width. I'm curious as to whether there is another label I need to modify like an offset or something to match this. I'll keep reading--

Also changed MAPDRW to match the offset of >8357. Effect was even worse than before. I imagine I misunderstand the labels.

Edited by Opry99er, Sun Jul 25, 2010 10:47 PM.

[adamantyr]

Opry99er, on Sun Jul 25, 2010 10:38 PM, said:

I changed the width to >8357 because the new map width is 87 instead of 84 as before.... The heights is curious to me though, because I don't think the map was 86 characters high... of course, that matters less than the width. I'm curious as to whether there is another label I need to modify like an offset or something to match this. I'll keep reading

The Equates aren't values, they're addresses on the computer. In fact, those are all in the scratchpad RAM, from >8300 to >83FF. They're pointers or storage locations for values. So at >8354 is a word-length value that stores the map width.

Adamantyr

[Opry99er]

Comprende. Thanks for the info.

[sometimes99er]

Wow, the RPG Maker sure looks cool. Some amazing 2D scenarios. There's even platforms like MSX2 and Game Boy Color on the list. I wonder if it would be possible to do something complying to the 9918A and 9919 standards.

[Tursi]

Opry99er, on Sun Jul 25, 2010 7:20 PM, said:

-In front of the real machine
-In Classic99
-In Notepad++
All great in their own way... of course, you can't test or debug with Notepad and without emulation or real

I guess the next big step in TI debugging is source-level debugging. The unfortunate side is that the object file formats don't have the information we need - but I've been thinking that if we also use a listing file, we should be able to do it... they contain all the labels as well as source line numbers.

[Opry99er]

Hey sometimes----

They have a 3d version as well... I'm not so much of a fan... 2d is my favorite for RPGs I think... =)

[sometimes99er]

Opry99er, on Mon Jul 26, 2010 5:32 AM, said:

They have a 3d version as well... I'm not so much of a fan... 2d is my favorite for RPGs I think... =)

Sure thing. I must be getting old. I can't play Counter Strike or anything 3D for more than 3 hours, then a fooking headache starts to kick in ...

[Opry99er]

Quote

guess the next big step in TI debugging is source-level debugging. The unfortunate side is that the object file formats don't have the information we need - but I've been thinking that if we also use a listing file, we should be able to do it... they contain all the labels as well as source line numbers.

Well, I've not tried any advanced debugging, but when I get a whacked out EA3 (Like I'm dealing with now on this scroll routine) I try as best I can to read through and determine where the source is screwed. Sometimes... like last night... I get a very embarassing wake up call like... "MAPDAT isn't a value, it's a memory location." =) Embarassing. Anyway, the hardest thing for me in assembly right now is understanding the abstract nature of it. As it's been said here before, with assembly-- you can do "anything." Writing it seems to be alot easier for me than understanding it on paper. Matthew's sample code is all very understandable and well written--- but it's not how I'm used to seeing assembly source written. All the custom VDP routines and beautifully constructed tables... it's quite lovely and works magnificently. But now that I'm going through and trying to make changes, I'm finding it difficult to pinpoint exactly what I'm trying to find and alter. It's a great exercise, and I'm actually glad that it hasn't been answered yet--- it's teaching me a ton! =) (that being said, if I can't figure it out today, I'll permanently declare myself a moron) =)

So I guess the point of all this is--- assembly is wonderful, and I love learning more about it. Thanks to the great teachers in the community, it's accessible for all to learn as well. I hope to have some new code to share soon. I've been working on a way to mock up (in assembly) the battle algorithm I've done in XB ... just as a test to see how complex the calculations will be. I guess sometimes you just gotta try and fail miserable so you can learn why and where you screwed up. I think having so many challenges and minor failures for me is a good thing. If I wasn't experiencing failure, errors, and bugs--- I wouldn't be learning anything. =)

[Opry99er]

OKay... MAPDRW is the offset... but I can't find a LI for MAPDRW anywhere in this source. If MAPW (map width) was loaded into MAPDRW, that would make sense to me... but then again, I was unable to write a routine as efficient as this one. Let me explain precisely what I'm trying to do here.

*I have been modifying my maps and I want to run this scroll routine with the new map data... so, simply dropping in the new map data didn't work... of course. I'm also wanting to do this for other maps as well... but I imagine that I will have to specify new "passable characters" as well... so I'm looking for the following pieces of info about your source, Matthew.

-What needs to be changed to allow a larger map size?
-What needs to be changed to allow me to specify new "passable characters"
-What needs to be changed to allow me to make my viewport larger
-What needs to be changed to allow me to move my viewport to the center-top of the screen?

I have made these changes successfully in my own source and I can edit it quite easily. But I am unfamiliar with all your new conventions. I would love to understand a bit better, so this is my plea. =) I am not going to be able to figure this out on my own looking at this source... My own source (with the much less efficient VDP boundary checks and not CPU boundary checks) is far less complicated but also grossly inefficient. Just goes to show--- short code doesn't make good code. =)

Thanks in advance here Matthew. Once I understand exactly what's going on in that source (including the MAPLOD section) I think I'll have everything I need to move forward. =) You rock man

[Opry99er]

how cool is that? Thanks Codex!!

[Opry99er]

Just wanted to post a little chunk of the overworld draft I've been working on. It's still very bare bones and whatnot... but I haven't posted in a while and I thought I'd show a bit... Nothing much. =)

[JamesD]

Progress is progress.

[Opry99er]

Another take on the scroller. =) More Zelda-like.

[unhuman]

Nice sound effects.

[Opry99er]

Unfortunately, that music will not be possible with the stock TI soundchip.

I've taken a break from this thread for a while.... I needed it. I spent the last hour reading through the thread and I've really come full circle in the past few months. I know how to do much more with my resources now, and I have a better grasp on both XB and assembly. Going forward, my goals are far less lofty for this XB version. It will be an RPG, but it will be an adventure style RPG... I will randomize battles, but it will not be as crazy as Legends. My goals for battle have been redefined and redefined over and over again. I now have a real understanding of what's possible for battle... I don't have a complete battle engine in place, but I have decided to go with a very simple framework of 2 or 3 variables which will determine outcomes of specific "moves".

This will be a very stripped down RPG for the XB version.. I'm adapting a simple "bottom up" approach for this project and hope to make simple progressive steps towards completion. Thanks to the help of Matthew and sometimes99er, I have some great assembly knowledge to go with the XB side of this. That video above uses a Matthew180 assembly support routine. And it's very nice.

[Vorticon]

Nice scrolling owen. And the graphics really look great! One suggestion: I think the scrolling should happen when the character is 2 or 3 characters from the edge rather than right at the edge so that one can see a little further ahead.

[sometimes99er]

Vorticon, on Sat Dec 11, 2010 2:46 AM, said:

Nice scrolling owen. And the graphics really look great! One suggestion: I think the scrolling should happen when the character is 2 or 3 characters from the edge rather than right at the edge so that one can see a little further ahead.

Very nice idea. Is it like that with Zelda ? The viewports would have to overlap a bit. Challenge.

Edited by sometimes99er, Sat Dec 11, 2010 9:51 AM.

[Opry99er]

I'd thought about this at one point.... But it almost adds another element of difficulty/strategy leaving it the way it is.... Then again, I really liked the idea a few months ago. . I will need to re-investigate and start playing with the code.... See if I can't make it happen. Thanks for the suggestion, Vorticon.

BTW, I can't remember if Zelda did this or not.... But this game is really not intended to be a "scroller" per se. More of a screen-by-screen adventure... Maybe it's all semantics, j don't know.

[sometimes99er]

Opry99er, on Sat Dec 11, 2010 9:46 AM, said:

BTW, I can't remember if Zelda did this or not.... But this game is really not intended to be a "scroller" per se. More of a screen-by-screen adventure...

Zelda (at least this one) does not overlap. Screen-by-screen.

Edited by sometimes99er, Sat Dec 11, 2010 9:57 AM.

[Opry99er]

This is pretty much what I hope to accomplish--- I really like the way the player SPRITE stays still in context of the map and moves across the screen WITH the scroll. Very nice piece of programming there. . I could probably do that with auto-motion and some trial and error

[Opry99er]

Although, in CALL LINK, I believe the interrupts are turn off which would prohibit auto-motion.... It wouldn't be difficult to move it pixel by pixel in XB.

[Tursi]

Don't use automotion, you'll spend forever trying to time it anyway. Just move the sprite as part of the scroll routine... it's just one extra VDP update, and the sprite table is in a fixed location in XB, so you're safe to move it from assembly.

[Opry99er]

Very cool. Thanks for the info.

[Opry99er]

Well, I'm returning from a month long road trip and catching up.... My work on this project hasn't stalled, just slowed while I was in travel/play mode these past few weeks. Here is what I plan to accomplish next on this game...

1) clean up scroll interface in XB
2) develop and implement PC stat/variable table
3) develop and implement enemy stat/variable table
4) work in my preliminary battle engine and test using the tables
5) develop an "encounter" formula to determine when and where battles will take place.

The last one (#5) is the one I wanted to address in this post. This is a real kicker for me. I had always indented on having visible and stationary enemies that (when touched) would begin battles against your PC, Beryl, and his party. This, however, will be next to impossible in XB due to character set limitations. So.... I have decided to go with random encounters. It won't be a hardcore random battle grind like some other RPGs.... It will be tasteful, I promise. There will be "battlefields" that one may enter (if he so chooses) and fight to gain experience, treasure, and items. Each battlefield may be entered 10 times before it is no longer useful. On the large world map, there may be s battlefield between a town and the next area in the story-- be it a forest or a river or something.... Anyway, the player doesn't have to fight all 10 battles in the battlefield to advance... Doesn't even have to fight one!! But the option is there, and it will hone your battle skills as well as give you power, gold, and XP. Your choice.

The "random" battles take place inside the levels.... Like the video I posted of the Forest world.... That is only one stop along the game route... The big map will contain the Forest world you saw, but will also have several other environments to visit. This is clear in my head, but for clarification, I plan to use the FF Mystic Quest model for the world map and smaller maps.... The battle initialization formula (for random encounters) will be more along the lines of FFII. These are available to watch on YouTube, so if anyone's interested--- check it out.

Sorry for being so absent lately.... Life is crazy!!

[Opry99er]

Wanted to post a repository of the "cooler" things that have transpired on the Beryl project here... I have attached a zipfile with several items in it... There is a table of contents included in the zip, but I'll re-post it here as well. My goal with this is to give people who don't know much about the project a single download to see all the interesting things I have done (with help in no small part from Matthew, Karsten, Adam, and others) with this project.

I have very recently begun a couple things with Beryl that I'm not planning on disclosing until they are further along, but you can DL this zipfile and experience the project as it currently sits. The zip includes the following. The only thing you'll need any additional info for is the "VIEW3" program in DSK2. Run it as a EA3 objectfile with the PROGRAM name of "MAIN". Should be self explanatory from there. DSK1 has a LOAD program, DSK2 has "BATTLEBR" which is just a XB program that runs with "RUN 'DSK1.BATTLEBR'" and a program called "BRICKWALK" which behaves the same. The "documents" file JUST contains documents in Notepad and Word formats.

Documents

*Blogs 1-5
*Beryl Reichardt history and story
*Game Outline and development doc
*Graphic Hex document

DSK1

*New link programs
	-LOAD
	-XB PROGRAM
	-Object file for assembly linkup

DSK2

*BATTLEBR (XB program simulating battle)
*BRICKWALK (A small program showing pseudo scrolling--Karsten's bricks)
*VIEW3 (Objectfile for Matthew Hagerty's scroller using the LAVA world graphics
*view (the source for Matthew's scroller)

FORESTOGGLE

*A FIAD disk containing a toggle program I wrote... shows all the areas of the OLD Forest World.

Enjoy!!!

Attached Files

•  ALLBERYL.zip   75.49K   2 downloads