emitter bug based on dimensions

Games
#1

Hi,

I faced a very weird bug with emitter … full code is attached!

I grabbed what seems to be an old but working code with emitters

The problem is when you set screen size in config.lua to:

320X480 code crashes in simulator and phone (Assertion failed)

When you set it to:

640X960 it works on simulator but crashes on phone (Assertion failed)

Finally setting it to 1080X1920 it works on both!!

Can someone tell me what is going on?

I don’t want to redownload my resources for the 3rd time to fit 1080X1920

Thanks.
OneTouch2.zip (1.0 MB)

#6

image
image726×56 2.53 KB

Here is nan value (dy value of transition)
image
image1177×231 9.25 KB

Quick fixed.

1 Like
#7

Check the console for the error and work back to find the source :slight_smile:

#8

Thanks man, that was really helpful

#11

Just chiming in here. The problem is specifically caused by the square root becoming negative at line 50, i.e.

local dy = (ranSign*math.sqrt((customEmitter.radiusRange*customEmitter.radiusRange) - ((dx - ex)*(dx - ex)))) + ey

If (dx - ex)*(dx - ex) is larger than customEmitter.radiusRange*customEmitter.radiusRange, then you’ll get -nan(ind), which crashes the transition.to call.

The proper way to fix this is to rethink your function, i.e. what should happen in those instances, or to ensure the value inside the square root is never negative, for example:

local dy = ranSign*math.sqrt( math.max( 0, customEmitter.radiusRange*customEmitter.radiusRange - (dx - ex)*(dx - ex) ) ) + ey

On an unrelated note, I understand this is some old code you just dug up, but given how this seems like something you’d be calling repeatedly, you may want to do some minor optimisation. For instance, you could create a local radiusRange variable inside the emit function so that you only need to do 1 table lookup instead of 8.

You’re also setting a bunch of variables to nil inside the transition’s onComplete listener, but that’s unnecessary. Setting customEmitter or group to nil only makes the references to these tables nil, i.e. the actual tables still persist. As for all of the other variables that are local to the emit function, they get cleaned up automagically when the function finishes as there will be no more references left to them.

1 Like
#12

Hi XeduR

I’m always happy when you reply to my posts

To tell you the truth when i saw the word assertion failed … i didn’t pay attention to what was written before it, and when i googled it (assertion failed) i didn’t get much, and since the problem appeared on phone but not simulator i thought it might be a bug
but normally i wouldn’t do this :grin:
Next time i will debug it to avoid getting attacked by aggressive developers here :slight_smile: who can spend hours attacking help seekers rather than spending minutes helping them!

the game is running now even without having to do what Kan98 helped me with, just because i modified the dimensions and redownloaded larger graphics which is wrong i know, but this is a game for one person only on one device, so i didn’t want to bother myself

I’m sure the code can be enhanced, but normally you purchase plugins or seek ready made classes to avoid writing extra code :slight_smile:

I preferer to write my own rather than debug someone else’s (As Long as I Can)

1 Like
#13

I don’t mean to sell Kan’s fix short, but it doesn’t address the root cause of the problem and it will result in the ey part of your equation being ignored.

If you change your equation to:
local dy = ranSign*math.sqrt( math.max( 0, customEmitter.radiusRange*customEmitter.radiusRange - (dx - ex)*(dx - ex) ) ) + ey

Then you will never have a negative square root, which means the rest of your equation will work. It will also make it so that you don’t need to check if the variable is invalid later on. You said you’re not planning on really working on this much as it’s just for your daughter, but replacing math.max with math.abs might be the actually proper fix for this issue.

On a different note, these forums (and the Discord server) are intended to be places where people can ask questions freely about developing games and apps using Solar2D. The first of the official forum rules reads: 1. Be Polite!. There’s no need for anyone to make snide remarks. If you see a post you don’t want to or know how to reply to, or you can’t reply in a helpful or polite manner, you can just let the post be and not reply.

1 Like
#14

A simplified version for your daughters app (that won’t crash). It is simple to amend…

local mainGroup = display.newGroup()

local function newEmitter(x, y)
    local rx = math.random(x - 30, x + 30)
    local ry = math.random(y - 30, y + 30)
    
    local p = display.newRect( mainGroup, rx, ry, 20, 20)
    p:setFillColor( 0.6, 0.6, 0.1, 0.5)

    transition.to(p, {time = 1000, x = dx, y = dy, alpha = 0, transition = easing.outQuad, onComplete = function(t)
        display.remove(t)
        t = nil
    end })
end

local function burst(event)
    for i = 1, 10 do
        newEmitter(event.x, event.y)       
    end 
end

Runtime:addEventListener("touch", burst)
#15

A retrospective… some are so quick to assign negative labels but a “thank you” for spending time to provide you with a bug free working version seems impossible to say eh? Have a great day :slight_smile:

#16

This thread will read very differently if I “undelete” your first two posts. Given that you deleted both of them, I’m sure you agree that they weren’t the thing to post:

image
image785×672 36.9 KB

I understand and I agree that a simple thank you for someone helping another person out is usually in order, but, in retrospect, if you start by first making snide remarks at the person asking for help because of the way they asked for help, then they might not be as willing to thank you later on.

Anyway, kakula’s issue has been resolved and we’re steering off topic, so I’m locking this thread. You can reply to me via other means if you want to.

2 Likes
#17