BB2 and Random Numbers

[DrkStarr]

Random numbers in BB2 are seeded. Yet it looks like you can't set the seed.

The Elmore library gets around this, and it's loaded automatically with the Ultimate CD install.

I can see I have the commands RRnd & RRandomize. When I look at the docs it says I should use RRandomize Ticks to set the seed.

But none of this works. With Ticks it's kicking out a 3 every time. I looked up RRandomize and it says that it counts the time since the last ResetTimer.

So I put a splash screen at the beginning with ResetTimer before it, and RRandomize after.

It looks like none of this helped.

Is there something else going on? Like with settings within the emulator? The commands are there, they highlight blue, but they just don't work.

[E-Penguin]

The problem is that emulators now are so good that they produce repeatable "random" behaviour. It impossible to have a genuinely random number in software alone. If you have the same starting conditions then you'll get the same numbers out. On real hardware you can do things like timing how long it takes to read the disk, as every machine is slightly different. You can introduce a bit of randomness by having a "press OK to continue" type screen and use that timing to seed the random number generator.

[Daedalus]

Yep, I'd second the plan of something like "Press fire to start" and counting the number of frames until fire is pressed. The CIAs have some very fast timers that could even be used to generate a larger number.

[DrkStarr]

Too bad emulators aren't more accurate. But I think I need a 68020 to run BB2, so getting that to slow down might never happen.

I did notice something odd when just plunging forward with it.

Using the MouseWait between splash screen and game does allow for random numbers. But the the first number that is generated is always the same. It seems the other numbers shift around, but that first one rolls a 1 every time.

Idk, maybe I could generate one number at the beginning and just throw it away.

[Daedalus]

You shouldn't need a 68020 for Blitz 2, but that aside, the emulated CPU doesn't have much bearing on speed when you're emulating unless you have cycle-exact options enabled.

Getting the same first number does indeed sound like a limitation of the random generator, so discarding the first number might be a good enough solution.

A little note on using Mousewait: it busy-loops, which is fine if you shut down the OS (i.e. use Blitz mode), but if you're in the normal multitasking Amiga environment it will have a heavy performance penalty. For testing that's no problem, but for a release a small loop that checks the mouse buttons and includes a delay would be better.

[E-Penguin]

Taking a value from the CIA timers is a good idea. Or mouse x, y position, or something else that's not predictable

[DrkStarr]

Originally Posted by Daedalus

A little note on using Mousewait: it busy-loops, which is fine if you shut down the OS (i.e. use Blitz mode), but if you're in the normal multitasking Amiga environment it will have a heavy performance penalty.

I noticed that after running the program for a bit, it started to really lag. And I was using Mousewait in the program. I took it out but I'm still running into creeping lag because I'm Opening and Closing Windows left and right. At least that's what I think it is. Is there a better way, maybe not destroying the Windows? I don't think you can hide them. And yeah, this is just a little program that runs on top of Workbench.

[Daedalus]

Opening and closing windows shouldn't slow things down like that really. Are you busy-looping in your code? Or what does your main loop look like? Ideally you should have some sort of delay in there, and there are a couple of ways of doing it. The first is to use WaitEvent to pause your program until an Intuition event that you're interested in is triggered, then react to the event and go back to WaitEvent for the next one. You can add the IntuiTicks IDCMP to the events you're interested in if youu would like to trigger your main loop roughly 10 times a second. WaitEvent is the best approach, but doesn't suit all cases.

The next is to use Event, which doesn't put your program asleep, so you should really do that yourself for the sake of the multitasking. A line like

Delay_ 1

in the main loop will pause the program for a single tick (usually 1/50 or 1/60 of a second) before continuing, which is enough to let other programs respond.

[DrkStarr]

I am using the WaitEvent and IDCMP to read events. The events mostly read pressing Gadget buttons. A lot of them will Close the Window you're in to open another. Where I'm seeing the lag is between this switch.

In the beginning the switch isn't noticeable. Checking it by dragging the mouse right after the click. But after a bit of running the program, I noticed lag between the click and the new page. It looks like the mouse hangs for a second. Slowly getting worse.

So I think I'm missing something here. Or at least I'd like to work around it.

[Daedalus]

Hmmm, that does sound strange alright... That shouldn't really be happening from the OS side anyway, though the debugger, while great, can slow things down significantly so it might be worth trying when that's disabled.

[DrkStarr]

Originally Posted by Daedalus

That shouldn't really be happening from the OS side anyway, though the debugger, while great, can slow things down significantly so it might be worth trying when that's disabled.

Well, I compiled the program and tried running it but I still see the same problem. This strange lag creep. It's not as bad, but it's there. Even with a fresh boot.

One solution I'm thinking about is using 1 Window, and turning gadgets on and off. I see that there is a toggle for this in the flag, but I have no idea how to set the bit. Any ideas?

[AestheticDebris]

Originally Posted by Daedalus

Yep, I'd second the plan of something like "Press fire to start" and counting the number of frames until fire is pressed. The CIAs have some very fast timers that could even be used to generate a larger number.

Or just read a random number on every frame and discard it. There's always going to be some inevitable variation in how many frames pass before starting the game. If your game is not on rails, you can use the same technique to add variance based on how quickly the player reaches points where randomness is required too.

[DisasterIncarna]

VALLIB lets you set a seed using RNDSEED <VALUE> so you can then use RND <MAX VALUE>, so you could set the seed using the above mentioned values, maybe adding mouse X and Y positions and throwing in other values likely to be different other than the timer value

You could do something bizarre like taking FreeChipMem+ScreenWidth and dividing that by MouseX and taking FreeFastMem+ScreenHeight and dividing that by MouseY, then add those values and use as a seed.

or use something less weird and straight forward

[Daedalus]

Originally Posted by DrkStarr

Well, I compiled the program and tried running it but I still see the same problem. This strange lag creep. It's not as bad, but it's there. Even with a fresh boot.

One solution I'm thinking about is using 1 Window, and turning gadgets on and off. I see that there is a toggle for this in the flag, but I have no idea how to set the bit. Any ideas?

Bizarre... If you wanted to share your source I could have a look later on. But if you can work around it, then that's also worth trying. You can disable and enable gadgets easily using GTDisable commands, they get hatched/greyed out when disabled but they remain part of the window. To actually remove the GTList, you need to detach it from the window, then redraw the window.

What exactly are you trying to do?

[DrkStarr]

I know this is getting off subject, but maybe I'm getting something wrong here.

I setup the screen, load some graphics, and switch to Workbench.

WBStartup
WBenchToFront_
Screen 0,11
ScreensBitMap 0,0
LoadBitMap 0,"assets/title.iff"
GetaShape 0,3,11,180,80
Cls
WbToScreen 0

Then I Init the first screen.

Gosub initTitle
WBlit 0,125,40

.initTitle
  Windows wndTitle,tempX,tempY,420,150,$140e,"",1,2,wndTitle
Return

After loading the title, I wait for a keypress, then:

Gosub initWndWain
Gosub drawLocation
Free Window wndTitle
currentWindow=wndMain
Use Window wndMain

.initWndMain
  TextGadget wndMain,220,20,0,1,"Travel"
  Window wndMain, tempX, tempY, 420,150,$140e,"",1,2,wndMain
Return

This is the way I open and close Windows. I draw the new window first, and then free the old window. The GadgetHit looks like this:

If GadgetHit=1
  Gosub initWndTravel
  Gosub drawLocation
  Free Window currentWindow
  currentWindow=wndTravel
  Use Window wndTravel
EndIf

At the core this is what I'm doing, and it might be wrong. I put this together looking at the reference manual.

[DrkStarr]

I just went through the code, line by line. With all those currentWindow variables I could've miss typed. All good there, but I did notice that I'm using Select Case pretty heavily, and I only plan to abuse it worse.

Could hitting this Select Case over and over again cause the type of lag I'm experiencing? It not there the first few times this routine runs, but it doesn't take long for it to start to affect the performance.

If it's the Select Case that slowing things down, the If Then logic would be even worse.

[Daedalus]

Nah, Select...Case constructs aren't going to cause that sort of thing. It feels like something isn't going right in terms of memory allocation / deallocation that's causing the system to hang briefly.

So what way are the window IDs managed? Is it possible some IDs are being mistakenly overlapped or something?

[DrkStarr]

Well, it looks like the program is falling through and creating another page in the background. I think it's just the one, because after bad lag there's only one when I close out, but there could be more.

What I did was put a MouseWait at the end of the program before Free Window currentWindow.

If I run the program to the main screen, closing out is fine. But when I start jumping around, commands must fall through creating more than one Window. I'm reading the EventWindow right after the GadgetHit and making that part of the condition to read the gadget on that Window:

Repeat
  Repeat
     ev.l=WaitEvent
  Until ev.l=$40 OR ev.l=$200
  eventWin=EventWindow

Then I'm trying to read the widow with:

If currentWindow=wndMain
  If eventWindow=wndMain
    If GadgetHit=1
ect.

Somehow that's wrong?

I tried FlushEvents at the end, before the loop restarts, but that's not helping.

[DrkStarr]

I traced it through the debugger, and it looks like that last Window is being created when I hit the Close Box. I put in an If Then Goto so when the Window is closed it drops right to the end of the loop. Now there's no other Window in the background.

I would like to step through the debugger with the space bar, hitting each line one at a time. But if I click something it cruses through code, making another Window. It's hard to follow what's going on. It happens pretty fast. I tried to turn Step on, but I don't think it works that way.

The windows are all number 0,1,2,3,4,5,6,7
0 is the Title Window that's only used once.

I was thinking that it's creating extra windows in the background, and that would slow it down. But I don't see that. Maybe if I could step through the debugger it would help.

[E-Penguin]

You can put a breakpoint everywhere you create a window, then see how it's getting there.

Also, as a coder with nearly 30 year's experience - you can't beat putting "print" statements everywhere to log the program execution, important variable values, etc.