Jump to content
IGNORED

"Sierra Maestra", an Early WIP


vidak

Recommended Posts

more tree graphics! i think i've figured this out.

 

This is how you can cheat and make easy graphics for the 2600:

 

  1. Get an image with a dark foreground and light background
  2. Open GIMP
  3. Under the Colours menu, select Levels
  4. Adjust the black and white levels so that the image you want to pixelate becomes incredibly dark. Adjust the levels so that the background becomes incredibly light. The image should look like a sharp silhouette.
  5. Open the Filters menu, and select the Blur submenu. Select the Pixelize option.
  6. Adjust the size of the pixels in the pixellated image so that you have roughly 8 blocky pixels width-wise. I usually adjust the height of the pixels so that they match the aspect ratio of the GRP0/GRP1 pixels.
  7. Copy over the silhouette image to Kirk Israel's PlayerPal2
  8. Play around with the image so that it looks beautiful. Usually GIMP will only be able to help you create an intermediate image that you then finalise in the PlayerPal.

post-61331-0-60143300-1523095924.png

  • Like 1
Link to comment
Share on other sites

 

more tree graphics! i think i've figured this out.

 

This is how you can cheat and make easy graphics for the 2600:

 

  1. Get an image with a dark foreground and light background
  2. Open GIMP
  3. Under the Colours menu, select Levels
  4. Adjust the black and white levels so that the image you want to pixelate becomes incredibly dark. Adjust the levels so that the background becomes incredibly light. The image should look like a sharp silhouette.
  5. Open the Filters menu, and select the Blur submenu. Select the Pixelize option.
  6. Adjust the size of the pixels in the pixellated image so that you have roughly 8 blocky pixels width-wise. I usually adjust the height of the pixels so that they match the aspect ratio of the GRP0/GRP1 pixels.
  7. Copy over the silhouette image to Kirk Israel's PlayerPal2
  8. Play around with the image so that it looks beautiful. Usually GIMP will only be able to help you create an intermediate image that you then finalise in the PlayerPal.

 

 

 

Hi vidak, the other day i saw your github and for your extension files i released that you use Gimp.

 

i use Gimp too :) and Lubuntu Linux

 

cheers!!

Edited by zilog_z80a
Link to comment
Share on other sites

I don't know programming in assembly language much at all.

I commend you for learning.

 

I wanted to share this idea:

As a "batari Basic" programmer, this code and logic is compiled into assembly.

I wondered if writing code and logic in batari Basic, then studying generated assembly could either help speed up learning asm, or be used to rapidly generate a complex operation?

It is true that some ways of writing your plain text basic source code, compiles into very wasteful assembly code.

 

And it can't teach you Kernel coding as those are fixed in batari Basic. It can't teach your HMOVE or sliding / skewing players, missiles.

But for game play code, math algorithms, ???, I feel the generated assembly from batari Basic could show one way of doing it. And since you understand what you've written in Basic, that has got to be much easier than figuring out what assembly source code is doing (unless it is well commended).

Link to comment
Share on other sites

Have you tried disassembling small C programs? They obviously work, but they don't look logical in ASM. They use strange sequences of operations to do simple tasks - hand written ASM is always more efficient in code density and overall speed.

 

Only really code written in ASM can be disassembled and then read as ASM - even then the output is difficult to comment and understand. You need a debugger and you need to be able to step through the code in an assembly monitor.

 

Would it be worthwhile having me write something on 6502 ASM? It is very easy to learn, and is a very beautiful instruction set.

Link to comment
Share on other sites

I didn't get my point across.

 

I'm only talking Atari 2600 6507 assembly, and that "batari Basic" compiles into 6507 assembly source. Commented source also if you use "rem" comments in your batari Basic code.

 

Using this fact, batari Basic can be a "tool" to learn from or to create an assembly source routine or subroutine that is beyond your current ability.

 

If that's still not clear, I would next need to show you an example.

 

Or it is fine to ignore my suggestion.

The assembly tutorials from Barari, Andrew Davie, and Spiceware are a great way to learn 2600 programming.

Link to comment
Share on other sites

How do you know, Jeremiah????!!!

 

 

That's covered in step 10 and its comments. An 8-bit LFSR's sequence will repeat after 255 values while a 16-bit sequence repeats after 65535. In both cases it requires the use of a proper tap value, for 8-bit there are 16 values that will work while 16-bit has 2048. If you don't use one of those tap values the sequence will repeat much sooner.

Link to comment
Share on other sites

Maybe this helps: If only one single bit remains after masking, then with a maximum length, 16 bits LFSR you get a 2^16-1 random sequence of single bits.

 

Actually a LFSR only creates one new bit per iteration, the other bits are mathematically somewhat related to each other. But a human player usually won't detect this relation and masking should not change that.

 

However in detail this depends on the implementation. If you e.g. have an 16 bits LFSR, only XOR the lower 8 bits and then read the upper 8 bits, then there is a good chance that players will detect a sequence here. Because then you only shift bits for the upper 8 bits. And e.g. when the upper 8 bits become all zero, then they will stay unchanged for some iterations.

 

BTW#1: In your code, you are using several bits more than once. So anything created from the same bits for sure has some relation. But again most likely not noticeable by a human player.

BTW#2: To inverse the XOR number of a reverse 16 bit LFSR you can use the following:

  • from shift right to shift left: (xx << 1) & $ffff | 1 (e.g. $00d4 becomes $01a9)
  • from shift left to shift right: (xx >> 1) | $8000
Edited by Thomas Jentzsch
Link to comment
Share on other sites


As has been pointed out masking is not going to effect the randomness


My guess would be that if you have unsatisfactory results with your

scheme it will be because the 6 bit numbers you mask off are too

correlated, they share too many bits.

eg if two share the least significant bit then they'll both either

be odd or even you wont get one odd and one even.

except it's worse (or may be worse) than that 'cause you have them

sharing more than one bit.

The simplest way to fix that would be to use a bigger RNG maybe 24

bits instead of 16, but that needs another byte of RAM


You might try stirring things up by some simple hashing

maybe choose 4 bits and use that to pick a number from ROM

at some random looking place in the program and XOR it with

your 6 bits probably using a different 4 bits a different 6 bits

and a different place in ROM for each of your 6 bit numbers

(they'ld still be correlated but it may be easier to make

them less correlated and it may not be as obvious)

Edited by bogax
Link to comment
Share on other sites

Awesome. Those are some great suggestions.

 

I am going to try and get the output of whatever RNG linked to the Environment Graphics pointers, and then we'll see what happens.

 

I was toying with the idea of avoiding random generation altogether, but I think I will stick with it.

Link to comment
Share on other sites

How do you know, Jeremiah????!!!

 

Thomas did a much better job explaining than I could have! My reasoning was simply that as long as you have a good sequence of 2^16 (minus one, apparently :D) numbers, you can trim off some bits without losing any randomness. I know that since it is an LFSR, it's a bit more complicated than that, but the apperant randomness shouldn't really be affected. All you're really doing is a mod 64. In C++, most times you will take an extremely large random number, and simply mod it with the range you want.

Edited by JeremiahK
Link to comment
Share on other sites

Okay I have had a think, and I think I am going to ditch the procedural generation.

 

My reasoning stems from a desire for good game design. I haven't even implemented the main game mechanic in the game, and I want to be able to teach people how to play the game as they play it. My current worry is that throwing people into a randomly generated world with very little structure, and very little easy scope for creating structure, will simply turn people off from enjoying the game.

 

I will create a reasonably linear world, and it will step players through a learning curve, and it will give the game a lot more structure.

  • Like 1
Link to comment
Share on other sites

aaalrighty.

 

i have designed the overworld. it is 171 screens. i think a 32KB cartridge will have enough space to store all the information for this.

 

there are bosses and mini bosses. you will have to defeat a boss in order to unlock another area - i imagine to get to the mountain summit, you will have 2 boss areas accessible, and you will have to defeat both in any order in order to get to the final area.

 

i think i will draw up the code and the lookup table for each screen on another day.

post-61331-0-86959600-1523932866_thumb.jpeg

  • Like 4
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...