Log In  

I know you've has problems with this before, so thought I'd post.

Inside _init() if I have the following code:

function _init(x)
    if(x)then
        ::g::   
        cls()
        if(not btnp(5)) goto g
    end
end

_init(2)

function _draw()
    print("working")
end

(Yes this is horrible code, but there's a char limit reason for doing it in the game I'm working on!)

Anyway, it works in this standalone situation - when you press X the game prints "working". But if I move the _init() code to my game it stops working. If I change btnp() to btn(), it works fine.

I don't know how else to help identify the problem, I used identical code in both situations, the only differences are that in my game there's a ton of other code in the file, and the init function is being called to re-initialise the game, from inside some other function (the argument for X is used to determine how to initialise the game), rather than being called globally as above.

Is there a limitation on _init() in terms of not being able to guarantee loops or other gameplay logic will work?
I know I'm using undocumented code here, could this be it?

EDIT: I tried it with documented code and the same thing happens:

if(x)then
 while not btnp(5) do
  --nothing
 end
end

Neil

P#48107 2018-01-13 03:31 ( Edited 2018-01-14 15:44)

I have a hard time following what you mean for your code to do, so I'm not sure I can offer useful information about the issue you're presenting, but I did want poke my nose in and point out something that might be tangentially useful to you.

Where you have this construct:

 while not btnp(5) do
  --nothing
 end

You could save a token by switching to this:

 repeat
  --nothing
 until btnp(5)

It's not a big deal, but if you're tight on space, it might help in a pinch.


As for the issue with btnp(), I think the -p() variants are really only guaranteed to work when used in tandem with the hidden main loop that's basically appended to your source code, which calls _update(), _draw(), and flip() over and over.

If you emulate/replace more of that loop, especially the call to (I think) _update_buttons(), you should be able to get btnp() to work properly. You might need to call flip() as well.

P#48108 2018-01-13 06:13 ( Edited 2018-01-13 11:16)

Thanks Felice,

>> I have a hard time following what you mean for your code to do

:) Yes it seems weird out of context. Basically I need my game to re-initialise under different scenarios, some of which require a "press x to continue" screen, and since space is an issue it's shorter to have the code inside _init().

Thanks for the token save!

>> I think the -p() variants are really only guaranteed to work when used in tandem with the hidden main loop

Ah, this makes sense. Would explain the inconsistent behaviour, thanks. I got round the problem in the end by using btn() and just checking for button up first so it didn't skip the screen entirely if they were already holding the button down.

Neil

P#48117 2018-01-13 08:53 ( Edited 2018-01-13 13:55)

Yeah, I've done the same thing in code that doesn't use the _update()/_draw() architecture.

We could probably generalize it to something like this:

function wait_for_btn(b)
    while btn(b) do end
    repeat until btn(b)
end

print("press ❎ to continue...")
wait_for_btn(❎)

It's all about signal edge detection, really. First fallen, then rising.

P#48166 2018-01-14 06:18 ( Edited 2018-01-14 11:21)

That's much more elegant than the workaround I had! Thanks :)

P#48170 2018-01-14 10:44 ( Edited 2018-01-14 15:44)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-28 14:55:49 | 0.008s | Q:15