vidak

From looking at the Jump2 paper Bogax posted, it does look like one can come up with a simple mathematical function for a vector of fixed number of jumps forwards and backwards on a Linear Feedback Shift Register. However Ockham's Razor would really favour the "single blank frame every screen transition" solution. You'd have 192x76 cycles to play with. I am really intruged by the maths of the fixed jump number vector though. I am gonna experiment with the math function just for fun, to see if it can fit into overscan. Why not have a bit of fun? It would make for insanely large RNG worlds if combined with the blank frame method. This is very typical of me, I make things way more difficult than they have to be. Another method that occured to me is to have maybe 2 8 bit counters, and swap between them when you move off the edge of one of them - like what happens in Fallout 4 - you only load certain areas into memory when you're actually in them.

Holy shit! Thanks Bogax! Also thanks Thomas Jentzsch! I'm not too bad with maths - so I may be able to wrap my head around this. I was thinking about running 2 counters in each dimension, but the problem is that doesn't necessarily solve the problem - it would only give you one row and one column of the world. For instance, you would get the same value on every Y coordinate of a /different/ X coordinate. So you'd move left and right, and the Y random number would stay the same. You could combine the two counters though... I wonder if XOR with a proper tap would create a sufficiently random but reversible number...

OKAY. First of all, in between finishing Phase Two of the game development and starting this new phase, I learned how to use git properly, so you can find the repository of the source code for this game here: https://github.com/bootlicker/guerrilla-game I was able to begin the work on the randomly generated overworld map today, instead of Tuesday. I think tomorrow will be busy, and I will be able to return to work on this on Tuesday. 16-bit Linear Feedback Shift Registers This person's blog series contains a useful rundown of exactly how a polynomial counter (a Linear Feedback Shift Register) works to create a one-dimensional sequence of pseudo-random numbers. I opted for a 16-bit LFSR because I thought I had the RAM left over to do so. I was initially very excited to try and build a large world based on the two bytes of RAM, which would afford 65000+ screens of randomly generated content. I imagined I could generate a 256 screen x 256 screen square world. I figured out that masking off 6 bits of the 16 bit number output of the LFSR would allow me to create 64 Choose 4 Combinations of unique screens across 65k+ screens. This would guarantee that virtually every screen on a 256x256 world would be a unique screen. A combination is the measure of the number of possible sets of some finite number of different objects that can be made from a smaller selection of that superset. A combination is different from a permutation because it doesn't care about the order of the smaller set of unique items. The fact that one of the superset's items appear at all makes a unique combination. If some other ordering of the same set of objects appears, combinatorial counting does not count that set again. The main problem is, 256 horizontal screens is too large a number of screens to calculate in order one at a time. This standard/famous code from batari takes at most 20 cycles to execute: lda Rand8 ; 3 3 lsr ; 2 5 rol Rand16 ; 5 10 bcc noeor ; 2 12 eor #$D4 ; 2 14 .noeor ; sta Rand8 ; 3 17 eor Rand16 ; 3 20 There are 37 x 76 cycles in Vertical Blank, and there are 30 x 76 cycles in Overscan, which means if I dedicated ALL the cycles in Overscan, which is currently empty for me right now, I would only be able to calculate at most 114 loops of the above. So there is clearly a computational limit to calculating new rows of content in this pseduo-two-dimesional method. I have done some brief research on two-dimensional LFSRs. This is the structure of the usual 2D LFSR: The CN network on the left are registers of identical length with different XOR taps. These different registers are then selected to output into a small array of registers of identical length. The control unit then chooses which output register to mux with which input register. N is the bit length of the registers, and M is the number of parallel registers. One register at a time is looped back around into the CN network, and one register at a time is outputted from the CN network. This confirms my suspicion - I think in order to reduce the amount of cycles required to compute some non-single iteration of the LFSR, a large amount of RAM would be needed. As I am writing this, I'm wondering if it isn't possible somehow to "buffer" the surrounding screens of the current screen the player might be inhabiting. Calculating the left and right screen only requires one iteration of the feedback register. I wonder if there's a mathematical trick to reduce the amount of cycles required to go through in order to calculate a new Y-index of the overworld, instead of a new X-index. Perhaps a lookup table? A lookup table could perhaps be used to do multiple loops through the feedback register, just a row up and a row down. It might be possible to do some algebra and find out what XOR $D4 to XOR $D4 to XOR $D4 to an unknown number is... Otherwise every movement up or down a Y-index is a full-row's worth of screens' calculations... There has got to be a faster way... Feel free to jump in and give your two cents! == On the other hand, one could remove the STA and LDA functions and speed the routine up quite a bit... You know, just have EOR $D4

Wow, very cool! I'm glad someone sorted it out!

Awesome! Definitely might make designing a kernel faster!

I think you need to slow down, zilog! A good strategy to learning something new is to learn things in steps! I'd say master drawing a single character using DoDraw first, then draw a 2LK using DoDraw, then master drawing a symmetrical playfield using a 2LK, then perhaps draw an asymmetrical playfield by itself, and then see how much other stuff you can fit in with timing constraints. I have found that an asymmetrical playfield uses up a LOT of cycles. It is probably the most difficult thing to fit into a kernel. Small steps! I started building my game step by step - I had no ability to draw even a /single/ multi-coloured sprite when I first set out. Even multi-coloured sprites take up a lot of time. You have 76 cycles per scan line, that really is not a lot!!

OKAY. I AM RETURNING TO THIS PROJECT. It has only been 39-40 days anyway. A lot of my friends and party members are always asking me about this game, and their positive encouragement recently has made me want to return to development. If I keep making games people are interested in, I think I'll never want to stop working on them! I still have a lot of time left in the kernel for drawing the screen, so I think I can return at some time and include playfield graphics or missiles. But I will do that later. I will call this next phase "Phase Three" - and I will dedicate it to creating a multi-screen world in which for you to move Che around in. "Phase One" was me learning how to draw the screen and a moving multi-colour character AT ALL, "Phase Two" was creating a multi-band kernel. What I want to achieve in Phase Three is a randomly generated multi-screen world. I think I will achieve this with a polynomial counter. Anguna has a 13x13 screen world. I think I'll aim for that size. I was thinking "how would it be possible to create a two-dimensional world using a polynomial counter?" I thought maybe I would have 13 individual different polynomial counters for each row/column of the square world, but after some daydreaming I thought perhaps a single polynomial counter that snaked down the world like this would probably work best: |-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-8-|-10|-11|-12|-13| |-14|-15|-16|-17|...|---|---|---|---|---|---|---|---| What would happen is that if you moved up one cell, the polynomial counter could decrement by 13 positions, and if you moved down a cell, it would increment 13 positions. The benefits of randomly generating a world are: I would not have to store a complete isomorphic representation of the world in ROM Players could still have the option of playing the same world again by entering a seed number Players would be able to share interesting worlds by sharing seed numbers Players would have the choice of randomly generating a world through a title screen menu Random generation would add replay value I don't fully understand polynomial counters yet, but I anticipate that a big disadvantage of using them would be that they would use up more RAM. However as I am writing this, I don't see how this would really be so, as the polynomial counter would really just be counting up and down for a single screen. The counter just moves up and down its one-dimensional pathway, and it gives the illusion that there is a permanent world cast out into two-dimensional space. Really there is just one screen, being loaded with different elements depending on what position the counter is at along its pathway. I will reduce the number of bands in the multi-screen kernel from 5 to 4. I want to give the moving enemies and friendly NPCs more room to randomly move around on the screen. As it stands, I am not happy with the amount of vertical room that NPCs have to move. So the polynomial counter will have 13 screens x 4 screen bands through which to step. I want there to be a sense of progression to the game, so I will add in a finite number of bosses. I am hoping that the polynomial counter will generate, say, the locations for 5 bosses randomly throughout the world without needing a separate subroutine, but what I may do is have the polynomial counter for the total world to distribute trees and NPCs, and, eventually, playfield graphics, and then a separate routine to nicely position the five boss garrisons throughout the world. I want the boss locations to be kind of like "castles" -- they'll be a barracks or a big building into which you enter. ====== Work timeline: I think I will be able to actually put some effort into coding on tuesday next week, because it's a holiday here in Australia, and my girlfriend has time off work and some family members are flying 4000km to come stay in my city for the holiday. ====== Social encouragement: Finally, I want to say that if you're like me, and you've been finding this year really hard emotionally, I'm always here to talk. It has been very difficult finding steady work, and I am not sure I actually want to continue in the career of academic philosophy after my PhD, so I am naturally feeling worried about my scholarship running out in 3 months. If you feel ashamed about yourself, and if you feel pathetic - I'm always here to listen. Depression is an artificial mental state. It is also temporary. The reason why you (and I) might feel depressed is not because of YOU (or in my case, ME). Everyone well-intentioned person in this Atari community is a wonderful person, and deserves to pursue a life and career that is fulfilling and satisfying. I have JUST gotten over a spell of deep, deep depression - AND paranoid delusions after testing to see if I actually do have schizophrenia, so I am very very relieved. I hope I can be the person to believe in someone else while they can't believe in themselves. I want this because I have so many people in my life who have believed in me while I couldn't. FIGHT IT. YOU CAN DO IT. FIGHT AND WIN. YOU ARE A GOOD AND WORTHWHILE PERSON.

Oh you're totally right. A reflected playfield is 20 pixels. I /thought/ the playfield was 4 times lower in resolution.

I guess you could whittle the plastic away... Anything's possible - maybe buy a few in case you mess up hahha

There is still a world of BBS servers out there! Telnet and usenet still function, and many 8bit and 16bit micros can be converted to use ethernet to connect to them.

Yeah I'm with the ASM or die faction, but I won't get in the way of the raspberry pi nanos in cartridges aping the 2600 hardware. I think the normative test for "aping" or "traditional" should be: is the code actually being executed by the 2600 hardware? Personally I don't care either way, but I will only evet write "traditional" 2600 code without acceleration.

So the playfield graphics are half the horizontal resolution of the player sprites.

The playfield graphics are 80 pixels horiztonally, if you wrote an assymetrica playfield. The player sprites are 160 pixels horizontally if you were able to draw a whole scanline of them.

I've been learning Ada, a very strongly typed language - and it's taught me a lot about C and BASIC. I think the 2600 really is so much about the hardware that you can't use strong typing. I agree it's too early to be talking about C for the 2600. What does having C over BASIC for the 2600 achieve? This is a genuine question, and not a snarky comment! Honestly I think the fact that precise timing is so critical for the 2600, the most powerful option will always be ASM.

The resolution for PLAYER graphics is 160x192

Awesome, thanks

- I started this thread in Contests, but that whole sub-forum is dead. I figured maybe this might be a good place to announce this idea. Okay. I got $250AUD for my birthday. This is the first discretionary spending money I've had since June last year. I was going to build something cool like a raspberry pi cell phone or build a homebrew 6502 computer. But it has all been done before. I always say I wanna give back to AtariAge because it has helped me combat my depression and psychosis, and has helped me develop as a person. I wanna use this prize money to stage a competition - is this allowed? Is this a good idea to promote activity on AtariAge? I am an ASM 2600 programmer, so my natural idea was to promote 2600 homebrew development - but I know there is a lot of 7800, Intellivision, and other consoles being developed for. I feel like it might be more fair to allow the competition to be a multi-platform contest. What do you think? If it was just 2600, I would put equal parts of the 250 towards dual first prizes for ASM and batariBASIC first prizes. What would be a good set of rules for a possible contest?

Okay. I got $250AUD for my birthday. This is the first discretionary spending money I've had since June last year. I was going to build something cool like a raspberry pi cell phone or build a homebrew 6502 computer. But it has all been done before. I always say I wanna give back to AtariAge because it has helped me combat my depression and psychosis, and has helped me develop as a person. I wanna use this prize money to stage a competition - is this allowed? Is this a good idea to promote activity on AtariAge? I am an ASM 2600 programmer, so my natural idea was to promote 2600 homebrew development - but I know there is a lot of 7800, Intellivision, and other consoles being developed for. I feel like it might be more fair to allow the competition to be a multi-platform contest. What do you think? If it was just 2600, I would put equal parts of the 250 towards dual first prizes for ASM and batariBASIC first prizes. What would be a good set of rules for a possible contest?

That's such an awesome story!! I really enjoyed reading that.

The big trick that masking achieves is transferring the work the CPU has to do in real-time calculation to pre-calculating it in ROM. It's a wonderful trick. In fact engineers in embedded programming do this. Instead of storing information in RAM, you store it all in ROM, and it saves space and speeds up performance. This is a good idea with the Atari 2600 seeing as we only have 128 BYTES of RAM. Because bankswitching is well understood now, you should make the ROM do as much of the work as possible. For instance what I've done for the GRP1 graphics drawn in the separate bands is just pad their graphics with $00 for 15 to 17 lines. This way if I want to move them vertically, I just adjust the pointer - I either load it sooner or later up and down the screen. This saves you many, many cycles. SkipDraw, DoDraw, SwitchDraw and FlipDraw are many times slower than just padding the ROM and messing with the pointer. Anyway, there is a good DoDraw 2 line kernel on 8bitworkshop.com under the heading Complex Scene 1 and Complex Scene 2. I learned a lot by studying that code.