vidak Posted April 7, 2018 Author Share Posted April 7, 2018 An example of the palm tree graphics in the game. Quote Link to comment Share on other sites More sharing options...
vidak Posted April 7, 2018 Author Share Posted April 7, 2018 i think i'm understanding better how to colour the canopy Quote Link to comment Share on other sites More sharing options...
vidak Posted April 7, 2018 Author Share Posted April 7, 2018 more tree graphics! i think i've figured this out. This is how you can cheat and make easy graphics for the 2600: Get an image with a dark foreground and light background Open GIMP Under the Colours menu, select Levels 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. Open the Filters menu, and select the Blur submenu. Select the Pixelize option. 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. Copy over the silhouette image to Kirk Israel's PlayerPal2 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. 1 Quote Link to comment Share on other sites More sharing options...
zilog_z80a Posted April 7, 2018 Share Posted April 7, 2018 (edited) more tree graphics! i think i've figured this out. This is how you can cheat and make easy graphics for the 2600: Get an image with a dark foreground and light background Open GIMP Under the Colours menu, select Levels 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. Open the Filters menu, and select the Blur submenu. Select the Pixelize option. 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. Copy over the silhouette image to Kirk Israel's PlayerPal2 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 April 7, 2018 by zilog_z80a Quote Link to comment Share on other sites More sharing options...
vidak Posted April 7, 2018 Author Share Posted April 7, 2018 No worries! If I have a choice, I always use Free and Open Source software! 1 Quote Link to comment Share on other sites More sharing options...
zilog_z80a Posted April 7, 2018 Share Posted April 7, 2018 No worries! If I have a choice, I always use Free and Open Source software! same Quote Link to comment Share on other sites More sharing options...
JeremiahK Posted April 9, 2018 Share Posted April 9, 2018 Yep, Linux and Gimp rock! About the random numbers, yes, you still have a sequence of 65536 numbers before they repeat with bitmasking. No special tricks needed! 1 Quote Link to comment Share on other sites More sharing options...
vidak Posted April 9, 2018 Author Share Posted April 9, 2018 How do you know, Jeremiah????!!! Quote Link to comment Share on other sites More sharing options...
iesposta Posted April 9, 2018 Share Posted April 9, 2018 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). Quote Link to comment Share on other sites More sharing options...
vidak Posted April 9, 2018 Author Share Posted April 9, 2018 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. Quote Link to comment Share on other sites More sharing options...
iesposta Posted April 9, 2018 Share Posted April 9, 2018 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. Quote Link to comment Share on other sites More sharing options...
vidak Posted April 9, 2018 Author Share Posted April 9, 2018 Ohhh I get you now. Use BASIC as a kind of ersatz outline of what I want to do in ASM! Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted April 9, 2018 Share Posted April 9, 2018 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. Quote Link to comment Share on other sites More sharing options...
vidak Posted April 9, 2018 Author Share Posted April 9, 2018 I understand that, my original question was how does the masking affect the randomness? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted April 9, 2018 Share Posted April 9, 2018 (edited) 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 April 9, 2018 by Thomas Jentzsch Quote Link to comment Share on other sites More sharing options...
vidak Posted April 9, 2018 Author Share Posted April 9, 2018 Thanks so much! Quote Link to comment Share on other sites More sharing options...
bogax Posted April 9, 2018 Share Posted April 9, 2018 (edited) 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 April 9, 2018 by bogax Quote Link to comment Share on other sites More sharing options...
vidak Posted April 9, 2018 Author Share Posted April 9, 2018 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted April 9, 2018 Share Posted April 9, 2018 (edited) You could XOR the two bytes and create another 8 bits that way which do not seem related. Edited April 9, 2018 by Thomas Jentzsch Quote Link to comment Share on other sites More sharing options...
JeremiahK Posted April 10, 2018 Share Posted April 10, 2018 (edited) 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 ) 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 April 11, 2018 by JeremiahK Quote Link to comment Share on other sites More sharing options...
vidak Posted April 12, 2018 Author Share Posted April 12, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted April 12, 2018 Share Posted April 12, 2018 Too bad. Instead you could control and limit the randomness initially and widen it later on. Quote Link to comment Share on other sites More sharing options...
vidak Posted April 12, 2018 Author Share Posted April 12, 2018 I guess I'm also still a beginner - I think maybe I am biting off too much for myself to chew too early! Quote Link to comment Share on other sites More sharing options...
vidak Posted April 17, 2018 Author Share Posted April 17, 2018 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. 4 Quote Link to comment Share on other sites More sharing options...
vidak Posted April 17, 2018 Author Share Posted April 17, 2018 I realised after making the map that I could randomly generate a maze, but I think I will stick with a static world because the bosses and overall game progression would not really change 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.