11 replies to this topic

[tschak909]

I am trying to gemerate random landscapes that will be vertically scrolled, but I need to generate the first frame, before anything else....

am looking for an algorithm that can generate bit batterns similar to the following:

PF1:

%11111111
%11111100
%11111110
%11110000
%11000000

PF2:

%00000001
%00000011
%00000111
%00000011
%00011111

PF0 will always be filled, so no worry there.

am wondering if I can start with an initial value, and temporarily generate another random value which would be the # of bits to shift left (in the case of PF1) or right (in the case of PF0) and do the appropriate loop which does the bit rotation, stores into the landscape... or is there a more efficient way to do it?

-Thom

[batari]

tschak909, on Wed Mar 7, 2007 12:50 AM, said:

I am wondering if I can start with an initial value, and temporarily generate another random value which would be the # of bits to shift left (in the case of PF1) or right (in the case of PF0) and do the appropriate loop which does the bit rotation, stores into the landscape... or is there a more efficient way to do it?

-Thom

Yes, you can use two 8-byte tables for the bit-rotated values. Should be more efficient in terms of speed and probably space too.

[tschak909]

Yeah, I was going to put the results of the algorithm into two tables, PF1Data, and PF2Data (starting from bottom to top), is this what you're referring to?

-Thom

[SeaGtGruff]

tschak909, on Wed Mar 7, 2007 12:50 AM, said:

I am trying to gemerate random landscapes that will be vertically scrolled

I guess your approach will depend on what you want the outcome to be like. If you're scrolling vertically and the playfield is defining the edge of a path or road, such that you have to stay within the boundaries as the road shifts left or right, then you might want to let the random number indicate which direction to shift in, and how much, sort of like you suggested. But if you want the shifts to seem more natural rather than artificial, then you probably want to avoid shifting back and forth too much or the road could zig zag in an unnatural fashion. Instead, you might want to generate a new random shift value only after a certain number of rows have been drawn with the current shift value, so that for example if you get into a curve then the curve will continue for a bit before it straightens out and then curves in the other direction.

Michael

[tschak909]

this is simulating a river bed, so jagged edges are okay, and welcome. at some point, I will alter the algorithm in response to a difficulty factor, but for now, I am just trying to get a working kernel... (the hero is a salmon swimming upstream.)

[batari]

tschak909, on Wed Mar 7, 2007 1:34 AM, said:

Yeah, I was going to put the results of the algorithm into two tables, PF1Data, and PF2Data (starting from bottom to top), is this what you're referring to?

-Thom

By tables, I meant use pre-bitshifted values instead of shifting in a loop. E.g. something like this, which is just one of the two tables, and assumes you have a LFSR-style random number generator called "rand"

  jsr rand
  and #7
  tax
  lda shiftdataleft,x
  
...

shiftdataleft
  .byte %00000001
  .byte %00000011
  .byte %00000111
  .byte %00001111
  .byte %00011111
  .byte %00111111
  .byte %01111111
  .byte %11111111

Edited by batari, Wed Mar 7, 2007 2:18 AM.

[tschak909]

ah! I get it! thanks

-Thom

[Cybergoth]

If you make bataris code a subroutine, you need only one table:

	 JSR GetPFValue
	 STA PF2
	 JSR GetPFValue
	 EOR #$FF
	 STA PF1

[tschak909]

Okay, I have it functioning now, but there is one slight fly in the ointment:

I am using this shifter generator:

;
; GetRandom - Get Random value, return into accumulator.
;
GetRandom	   lda RANDOM
				beq XSEED
				lsr
				bcc SRAND
XSEED		   eor #$A9
SRAND		   sta RANDOM
				rts

but according to that logic, anything that's a zero is interpreted (rightly so...) as a need to reseed... sooo what i'm wondering.....

should i put an additional random generator that determines whether or not to pass a zero or continue through the routine.... or? ... hmm, just thinking out loud...

-Thom

[Cybergoth]

jsr rand
and #7

Would still be 0 for 31 out of 32 cases, so I'd not worry about it

[Thomas Jentzsch]

Don't use $A9 for EORing as it doesn't give you a sequence of 255 different numbers.

Use e.g. $AF or $D4 instead.

[tschak909]

I really have to say, this is perhaps one of the single most solid communities i've ever seen on the Internet. (and this is coming from about 25 years of online experience (both BBSes and since my first ARPAnet access in 1988...).. I've watched, read, and looked at how you guys band together to help make a game a reality, and it makes me smile. It's because of the combination of the challenge of programming the 2600, and the way you all pitch in to help that has inspired me to finally do a game. :-)

-Thom

.....and now, we return to our regularly scheduled post.

I'm about to attempt grafting on a 6 digit score, (am reading source snippets first), and then i'll continue on working on the landscape generation, but for now, I have a sort of working kernel:

<-- YAY

Edited by tschak909, Wed Mar 7, 2007 5:51 PM.