Berylrogue

[matthew180]

You should run both the XB and AL versions to compare, although I don't recommend you use a full screen maze for the XB version. It is the same algorithm, yet XB takes about 3 minutes and the AL version less than 16.6 milliseconds. :-)

 

Matthew

[Opry99er]

Yea--- the XB game "Legend of Beryl Reichardt" will have pre-designed map graphics... I am going to design a draw routine for these maps though... Load them all into low memory and CALL LINK them at the appropriate time. If you want to see a demo of the entire Forest World, I have it saved to my Beryl thread. It's a DSK1 file that contains a LOAD program, an XB program, and 6 datafiles. It's a pretty neat little demo--- I will be doing this with each of the Worlds I create--- with a little bit of modification--- I'll probably add subtitles and a little menu screen. This will allow me to have a virtual tour of the game.

[Opry99er]

I've been playing around with assembly quite a bit lately preparing for this game. I should have some cool stuff to show soon. Thanks for the help on map generation. I'm still a bit lost on the whole concept, but the more I look at it, the more I kind of understand the concept. It's pretty interesting... But I may cheat and create the illusion of a random map generator--- I'll have it reveal itself in the classic Roguelike style, but I may go ahead and design the whole thing. I'm struggling with this idea because I want to make it true to the roguelike model--- but I could really control the gameplay and story if I pre-designed the world. Who knows. I'll keep truckin' along

[Opry99er]

This is NOT a demo of the game. This is not THE game. This is just my first assembly success and I wanted to share it here. =) I've attached a zip containing the objectfile. Anyway, it's just the stupid Berylrogue screen I did at the beginning of this thread-- I then placed an X on the screen and you can move it around with the arrow keys (or joystick on the real TI). It doesn't do much, but you can move the character around. There are no barriers or screen parameters, so you have to keep the X inside the screen or you get a lightshow and a lockup after a couple moves outside the screen. =) I have a version with comments for each line, but it won't keep its format when I paste it. If you're interested, I'll comment each line and explain what each one of these lines does.

 

This is an EA3 file (Load and Run).

 

*Put this in DSK1

*Use option 3 of the Editor Assembler

*FILE NAME is "DSK1.CRAPO" (without quotations)

*When it asks for another FILE NAME, just hit enter

*Program name is "START" (without quotations)

 

This is not very interesting... it's just a learning step.

 

 

 

  	DEF  START
DEF  MAPDAT
  	REF  VMBW
REF  VSBW
  	REF  KSCAN
START
  	LI   R0,0
  	LI   R1,MAPDAT
  	LI   R2,768
  	BLWP @VMBW

  	LI R0,300
  	LI R1,>0100
  	MOVB R1,@>8374
LP 	BLWP @KSCAN
LIMI 2
LIMI 0
  	CLR  R1
  	MOVB @>8376,R1
  	CI   R1,>0400
  	JNE  T1
  	AI   R0,-32
  	JMP  PG
T1 	CI   R1,>FC00
  	JNE  T2
  	AI   R0,32
  	JMP  PG
T2 	MOVB @>8377,R1
  	CI   R1,>0400
  	JNE  T3
  	INC  R0
  	JMP  PG
T3 	CI   R1,>FC00
  	JNE  LP
  	DEC  R0
PG 	LI   R4,3000
  	DEC  R4
  	JNE  $-2
  	LI   R1,>5800
  	BLWP @VSBW
  	JMP  LP

MAPDAT DATA >2020,>4245,>5259,>4C20	;
  	DATA >2048,>5020,>3335,>2020	;
  	DATA >2020,>2020,>4C49,>5645	;
  	DATA >5320,>3220,>2020,>2020	;
.
.
.
.
768 total bytes

CRAPO.zip

Edited May 11, 2010 by Opry99er

[+adamantyr]

This is NOT a demo of the game. This is not THE game. This is just my first assembly success and I wanted to share it here. =) I've attached a zip containing the objectfile. Anyway, it's just the stupid Berylrogue screen I did at the beginning of this thread-- I then placed an X on the screen and you can move it around with the arrow keys (or joystick on the real TI). It doesn't do much, but you can move the character around. There are no barriers or screen parameters, so you have to keep the X inside the screen or you get a lightshow and a lockup after a couple moves outside the screen. =) I have a version with comments for each line, but it won't keep its format when I paste it. If you're interested, I'll comment each line and explain what each one of these lines does.

 

This is an EA3 file (Load and Run).

 

*Put this in DSK1

*Use option 3 of the Editor Assembler

*FILE NAME is "DSK1.CRAPO" (without quotations)

*When it asks for another FILE NAME, just hit enter

*Program name is "START" (without quotations)

 

This is not very interesting... it's just a learning step.

 

 

 

  	DEF  START
DEF  MAPDAT
  	REF  VMBW
REF  VSBW
  	REF  KSCAN
START
  	LI   R0,0
  	LI   R1,MAPDAT
  	LI   R2,768
  	BLWP @VMBW

  	LI R0,300
  	LI R1,>0100
  	MOVB R1,@>8374
LP 	BLWP @KSCAN
LIMI 2
LIMI 0
  	CLR  R1
  	MOVB @>8376,R1
  	CI   R1,>0400
  	JNE  T1
  	AI   R0,-32
  	JMP  PG
T1 	CI   R1,>FC00
  	JNE  T2
  	AI   R0,32
  	JMP  PG
T2 	MOVB @>8377,R1
  	CI   R1,>0400
  	JNE  T3
  	INC  R0
  	JMP  PG
T3 	CI   R1,>FC00
  	JNE  LP
  	DEC  R0
PG 	LI   R4,3000
  	DEC  R4
  	JNE  $-2
  	LI   R1,>5800
  	BLWP @VSBW
  	JMP  LP

MAPDAT DATA >2020,>4245,>5259,>4C20	;
  	DATA >2048,>5020,>3335,>2020	;
  	DATA >2020,>2020,>4C49,>5645	;
  	DATA >5320,>3220,>2020,>2020	;
.
.
.
.
768 total bytes

 

Don't be afraid to experiment or try things out... just congratulate yourself that you were able to write a working assembly program.

 

One thing you should consider at this stage is that your maps will probably be stored in a CPU buffer. That means any edge checking or object interactions would be done there. The best way to treat the TI display for optimal efficiency is as a pure display port, nothing more. You could do what you normally do in BASIC, using GCHAR, but this is really slow, even in assembly.

 

I suggest you try out for your next assembly experiment the concept of a map in CPU memory, and only displaying a portion of it on screen, and make your "scrolling" map.

 

Adamantyr

[Opry99er]

Could you be a bit more specific about what you mean by "viewport?". Additionally, what other methods are there for creating barriers and such? I've been studying the HK source Matthew posted, but I'm still not sure. Anyone have a suggestion for reading or maybe a bit of commented source?

[Opry99er]

BTW, a chunk of my source for creating a motion sequence came from the Lottrup book, but required some massaging, as it was written for Minimem and LBL. I'm going to be putting some miles on Filips toolkit!!!

[+adamantyr]

Could you be a bit more specific about what you mean by "viewport?". Additionally, what other methods are there for creating barriers and such? I've been studying the HK source Matthew posted, but I'm still not sure. Anyone have a suggestion for reading or maybe a bit of commented source?

 

Sure. The idea here is that what the user sees is a finished product before you even touch the VDP port. The only thing you're doing with VDP is direct writes/reads with no logic other than a single loop.

 

For example, your map data does not necessarily need to be one byte per space. You could store the data in only 2-bits (open, wall, corridor, door) and then track actual objects in the dungeon (monsters, treasure, traps) in a separate memory area. This is a way to optimize your data structures; complex objects are kept separate from simple ones, like walls and corridors.

 

So then you have "map processing" going on. You'd extract the map data, and plot this into a display buffer in CPU memory (whatever size on screen, if you used two rows for statistics it would be 32x22 or 704 bytes). The four types would have tile display characters in a small indexed array to use for populating the buffer. Then you'd go back and check each object's position to see if they're within the window's range. If so, then you plot those individually into the buffer. Finally, you actually write the buffer out to VDP at the screen location in one linear swoop.

 

As for checking movement, it's a good idea to pre-load a data array with all the tile types around your player while map processing a new move. That means you can do a single quick check to see if they can move that direction or not. Interaction with objects can be handled in a similar manner, although if doing real-time it may get complicated. (As in, monsters move even if you're not, but that's not technically a Roguelike.)

 

Adamantyr

[Opry99er]

Well--- that's excellent info, and just a bit over my head at this point, some of it. I'll start small and post some code--- I appreciate your willingness to help and I hope it continues as I learn more.

Edited May 12, 2010 by Opry99er

[sometimes99er]

You could do what you normally do in BASIC, using GCHAR, but this is really slow, even in assembly.

Well, still Assembly is much, much faster than Basic (even using a GCHAR-like method).

 

Edited May 12, 2010 by sometimes99er

[Opry99er]

Starting to think about this again for the possible BBS project we've been discussing. This could be a playable game via BBS linkup. I looked at my assembly code here and it's pretty sad. . With Adam's discussion recently about random seeding/mapping and how it works, it really makes me excited to look at this again. Calimari Carl first though. I have put the roguelike off for way too long... The TI NEEDS a roguelike, and my storyline is already written... Just need to get serious.