[Graham]

First question: SprN_setview does not work with an unbound sprite, correct?
Second question: does the draw order of sprites change when you introduce unbound sprites? it appears an unbound sprite with a lower sprite number is now appearing above higher numbered sprites. it's as if spr_yorder is set to 1 because two unbound sprites changed draw order as they passed through one another.
Third question: what is with the text box and all text within it appearing black when an unbound sprite is present on the screen. is this a bug?

more questions to follow I'm sure. Thanks

[Dr Lancer-X]

First: Correct. It might be a good feature though - there's not really any good way of handling setview but I suppose the least terrible way would be to round to the nearest grid position for the purpose of the calculation.

Second and third: These sound like bugs, please provide steps to reproduce / example .MZXs and post in the Bug Tracker. The draw order of sprites should not change and I'm not sure which text box you're referring to but it almost certainly should not appear black. Note that your renderer (your video_output config option) is important when it comes to unbound sprites so make sure to mention that as well.

[Lachesis]

While the latter two do sound like bugs, just a word of warning about converting an existing game to unbound sprites and especially variable color indexing: you might have to toss a lot of assumptions about the way regular MZX sprites and SMZX indexing behave out the window for it to work the way you want. If you aren't doing so already, I recommend experimenting with unbound sprites in self-contained test worlds in tandem with your work to make sure they behave as expected (and to have something lightweight to share when you encounter a bug).

I spent several days just getting my game to display objects and the menus properly and had about a bazillion mysterious graphical issues that ended up being mostly minor mistakes in my code or me not accounting for the way some other thing was running (if you're using SMZX indexing, note that setting SMZX_MODE will reset your indices).

The third thing you listed specifically sounds like a glsl renderer specific bug. Have you tried opengl/opengl2/overlay? What is your graphics card model?

[Graham]

Lachesis, on 03 July 2017 - 06:10 PM, said:

While the latter two do sound like bugs, just a word of warning about converting an existing game to unbound sprites and especially variable color indexing: you might have to toss a lot of assumptions about the way regular MZX sprites and SMZX indexing behave out the window for it to work the way you want. If you aren't doing so already, I recommend experimenting with unbound sprites in self-contained test worlds in tandem with your work to make sure they behave as expected (and to have something lightweight to share when you encounter a bug).

I spent several days just getting my game to display objects and the menus properly and had about a bazillion mysterious graphical issues that ended up being mostly minor mistakes in my code or me not accounting for the way some other thing was running (if you're using SMZX indexing, note that setting SMZX_MODE will reset your indices).

The third thing you listed specifically sounds like a glsl renderer specific bug. Have you tried opengl/opengl2/overlay? What is your graphics card model?

Graphics card is an NVIDIA GeForce GTX 765M. I tried opengl1 & 2 and got the same result. I tried overlay1 & 2 and because overlay2 does not currently work correctly with the advanced graphical features and disables them, I am able to see the text box and text rendered in the correct colors.

I will report this over in the bug tracker as well and include a copy of my game. I haven't been able to isolate the problem for you yet and put it into a game with less overhead.

This post has been edited by Graham: 04 July 2017 - 08:10 PM

[Dr Lancer-X]

I pushed fixes for #1 and #3 (as well as a temporary recommendation for #3- see the tracker thread). #2 is remaining unfixed-- in unbound sprites land every sprite is a separate layer, so it doesn't really make sense to have the kind of layer intermingling required to have something above a sprite but below overlay when the sprite it's above is itself above overlay.

[Graham]

Dr Lancer-X, on 04 July 2017 - 03:38 PM, said:

I pushed fixes for #1 and #3 (as well as a temporary recommendation for #3- see the tracker thread). #2 is remaining unfixed-- in unbound sprites land every sprite is a separate layer, so it doesn't really make sense to have the kind of layer intermingling required to have something above a sprite but below overlay when the sprite it's above is itself above overlay.

That helps very much, thanks!

[Graham]

OK, so before I embark on this incredible adventure I'm about to partake in I just want to double check, the best method to convert between an unbound sprite's X/Y coordinates and the board X/Y coordinates is to create expressions that use *8 & /8 for X and *14 & /14 for Y?
that is the simplest, quickest way I can think to do all of the screen scrolling and position checking I need my robot to do for my player sprite. Am I missing anything? Thanks again

This post has been edited by Graham: 06 July 2017 - 02:34 AM

[Dr Lancer-X]

Yep. I mean, you could round that, but it might not matter depending on what you're using.

[Graham]

Dr Lancer-X, on 05 July 2017 - 06:37 PM, said:

Yep. I mean, you could round that, but it might not matter depending on what you're using.

ok, thanks

[Graham]

I haven't had time to look into unbound sprite collision much, but it appears that it's per pixel? It would make things much simpler for programming my game to keep the original bounding box that my player had when it's sprite was not unbound. is there any way to achieve that?

[Graham]

is if c?? Sprite_colliding N at X Y thenl "label" pixel based or board coordinates still?

[Graham]

I think I found the answers I was looking for. sprite_collion is obviously pixel based. All I had to do was just think about that one. I think the solution to the collision problem is to check for collision in the CENTER of the block next to my player, rather than checking for collision at the blocks edge. This should hopefully give me the result I'm looking for.