TwentySixHundred

Thanks it;s from a game of mine and no worries it's what learning is all about RT's 'commands' page is definitely worth flavoring in your browser for cross referencing.

No problem, There really isn't right or wrong ways about it and many of methods people use. You only gotta have a read over at stackoverflow.com to see how many methods and theories people have to battle the age old issue of not so randomness. Computers in general struggle to provide true randomness as they calculate perfectly without imperfections. Randomness is caused from imperfections so it's not easy to replicate. As for what i was trying to achieve, the method i was using basically was within a range of vales. So i wanted a random number from 4 to 154 IIRC and because rand uses the full byte i had to implement some math. This was to make sure if the value is out of range it would divide that value. IMO this division itself causes alot more patterns to appear because the math is set in stone (that's debatable and my observations). It seems the more math involved the more patterns emerge also mentioned my Spicware. Now as for randomness and if you're wanting to use the full byte (0-255) it's alot easier to remove the patterns. From my end of experimentation with random number generation i have found what works for me and it's actually fairly simple. Basically like mentioned in the beginning using a counter variable really helps mix things up, rather then relying on the pseudo random number generated by the rand function. As batari's rand function IIRC seeds from 0 and cannot be changed AFAIK, it's highly likely for rand to produce the same number especially on the first call (common with every language it's just with some you can change the seed). So what i like to do is less complex then you probably think: dim counter = z rem -------------------------main----------------------- _main counter = counter + 1 blah othercode blah othercode if blahblahblah then counter = counter + rand : goto _desired_outcome _drawscreenloop drawscreen goto _main rem ----------------------- end of main ----------------- _desired_outcome blah blah blah goto _drawscreenloop So you can see the counter variable is incrementing every loop and continuously rolling like a slot machine. Then the if statement is checking for a condition i called blahblahblah if that condition is met then it grabs the counter value and adds rand's pseudo number. So everytime you call rand no matter if it has a pattern or not, it's mixed up with that rolling value you add from the counter. Basically it's just calling rand and whatever that rolling value is from counter then adds the two together giving a completely random number everytime. Although there is still the chance of hitting the same number twice like the luck of slot machines. All you need to do is read 'counter' after the (counter = counter + rand) math is complete, to pluck you random number. -Anthony

Just opened your program in ADS and compiled. So to start with, as you have kernel option player1colors, you can only define player1's colors and not player0. Secondly you haven't initialized the position of player1 during start up. I have made those quick changes and all looks good to me, here is the .bas file. default.bas

It's been awhile since i have used the standard kernels however if my memory serves correct you playerXcolors can only be used with multisprite or DPC+. You would have to set the sprite colors using COLUP0 or COLUP1 unless you change the kernel.

Ok so i opened your program in batari and compiled, im thinking you're after something more like this. If so you will need to add a restrainer so it only allows one change per input. random_condition3.bas

Try this i forgot to add rand. random_condition2.bas Either way though i would be adding a counter variable like we were talking about for the math.

Thats because you have no condition, when you press fire you need to call the rand function. Have a look and see if you can spot the change i had made *untested code*random_condition.bas

Yep very much what i have used, you can even have that counter variable increment every frame and call a rand value to that variable before needing to use it. That way the counter value is constantly changing 60 times a second avoiding any patterns to appear, provided that call function is on demand rather then timed. It's one the most cycle efficient methods i have found so far without the need of complicated math routines. Something like this _main counter = counter + 1 if _blahvar_1 && _blahvar_2 then counter = counter + rand : goto _blah_label drawscreen goto _main I use this method for the random placement of the power station in City Defence, also very similar for the random warhead spawning.

I was talking about this awhile back, that random generation is not so random. Basically your best bet is to set a variable that can be used for the random number and you can preset it's seed value. Check this topic as it may help

Well without the source it's not so easy to see whats going on. Something like this should give you an easier guide to see how restrainers work and is similar to what i used with City Defence menu. All you need to do is use additional bits for the tracking of various options MENULOOP ; jumps to game if joy0fire then goto GAME ; restrainer function (skps inputs) if menurestrainer{0} && joy0left then goto MENUDRAW if menurestrainer{1} && joy0right then goto MENUDRAW ; resets bits ready for next input if !joy0left then menurestrainer{0} = 0 if !joy0right then menurestrainer{1} = 0 ; checks if bits are in off state and input detected - if so then flips those bits on if !menurestrainer{0} && joy0left then menurestrainer{0} = 1 if !menurestrainer{1} && joy0right then menurestrainer{1} = 1 ; for joy0left input conditions if menurestrainer{0} then goto NEXT1 ; for joy0right input conditions if menurestrainer{1} then goto NEXT2 MENUDRAW ; screen setup DF0FRACINC = 128 : DF1FRACINC = 128 : DF2FRACINC = 128 : DF3FRACINC = 128 DF4FRACINC = 255 : DF6FRACINC = 255 drawscreen goto MENULOOP rem --------------------------------------------------------------------------------------------------------------------- NEXT1 blah blah stuff for player goto MENUDRAW NEXT2 blah blah stuff for player goto MENUDRAW

Yeah exactly the same just change out joy0fire for joy0right or whatever direction you want. Basically all it does is flips a bit depending on what state that input is in (0 or 1). The if statements just skip the input codeblock until its in an off state again

RT Site

Using this method you will need to add a statement for when player1 is less then player0, add this aswell if player1y < player0y then p1y = p1y + 0.5 Im assuming what you're experiencing is when your player is above player1 it goes full speed As for the speed being too slow - you will need to tweak the value as desired

Hi guys, just wanting some feedback as i have updated to a new laptop. One thing i have noticed is major colour and brightness differences between the two laptops. Are the colours and luminosity i used really that dark for City Defence? The whole game looks very very dark, it actually looks terrible to me on this new laptop. Some confirmation would be great so i know it's not this laptop just displaying everything dark. If it really is as dark for others as i am now just noticing then i will probably tweak all the colours and luminosity values

As for overcycle and pfpixel when too many pixels are flipped on a single frame you can just set a _skp label if one those flip conditions are met. Provided, if all your condition statements are in a single code block and a pfpixel flip is executed then goto _skp label. This will ensure for that frame the pfpixel command isn't executed more then once per frame. Spreads the load over multiple frames

Yep, from my experience and experimentation i get the same results that pfpixel can be very costly in both ROM and cycles. I suspect when the code is cross compiled to asm it bloats substantially causing high ROM usage and demanding lots of processing time. It;s all good for a few pixels flipped a frame yet drawing full screen is not even feasible with the pfpixel command. It seems data tables is the better method

That's the difference with DPC+ over the standard kernels as the graphics data only needs to be set once and doesn't need to be updated every frame. Im sure making a change to individual bit's of sprites wouldn't be much different from pfpixel as it's preloaded into the melody RAM (DPC+). That means rather then altering ROM (which you obviously can't) you can however alter RAM which DPC+ uses.

ypos could be limited to 255 from 0 @ top to whatever the programmer desires further down the sprite. That way the full sprite length can be utilized as per normal functionality. This would allow for "scrolling" sprites to be changed on the fly using code for pixel flipping rather then a sequence of animated sprite data. So for instance you could have "player0pixel 7 200 flip" and have that sprite move upward meaning when the 200th line makes an appearance bit 7 on line 200 would be active. For the next complete scroll the programmer could have the pixel deactivated. This would give the illusion much like scrolling playfield does. Either way this would open many possibilities

Banks wouldn't be an issue with DPC+ as it reads the full 32k ROM rather then separate banks. I don't think it would be too hard to implement as the code would be very much like pfpixel code. The next question is, would anyone on the bB team have the enthusiasm to add such a feature. I know many of them are busy working on their own projects ect. Personally i like the feature that much i would if i had the knowledge of the kernels. However i haven't cracked them open yet nor learnt how they work. I really like the feature though and think it's worthy to be added to DPC+ atleast. I can think of multiple times i would use this rather then creating new sprites for simple animations.

If it worked much like flipping playfield pixels i can't see why not TBH. Something like player0pixel 0 7 on For example reference I agree it would be very useful 😎

Backers practicing their social distancing in the lineup for their AtariBawks!

Interesting, i wouldn't mind playing around with this in a test program. I am assuming you're wanting something like bit operators for the player graphics. Not sure if it's possible however i would like to think it is. Basically something like if player0{7} then player0{7} = 0 Not sure how one would edit more the a single byte though, nevertheless it would be a great feature 👍

Ok so if your condition is in the maingameloop you will want to skip the routine unless the condition is met. So as an example something like this: if switchselect then goto _restrainer else goto _skpblah goto sprites _restrainer if !switchreset then gosub _switchhero : goto sprites goto _restrainer _skpblah _switchhero t = t + 1 : if t > var7 then t = 1 : gosub _sound2 bank5 return I dont know exactly how your program is written so im taking a guess of whats going on

The basic concept is either using bit operators as an on/off switch or you can use labels. You can use labels if you're not wanting to use bits, for instance: mainloop blah blahblah if switchselect then goto _restrainer goto mainloop _restrainer if !switchselect then goto _blahblahblah goto _restrainer That's the basic concept, it jumps to the restrainer routine then jumps to whatever routine you're wanting when the switch is released.