KanedaFr Posted October 8 Share Posted October 8 Hi there, I'm using rmotion to handle my sprites' movement. I'd like to desactivate them when they reach a certain position. so I use test() and inactive() Unfortunately, it seems inactive() hangs or falls into an infinite loop.... My game doesn't hang when I use stop() and not inactive(), but it doesn't suit my needs: Sprite is still used on collide detection and I can't detect if it is available or not for reuse (sprites pool) Could anyone confirm this ? or perhaps correct me if I missed something ? thanks Quote Link to comment Share on other sites More sharing options...
KanedaFr Posted October 9 Author Share Posted October 9 inactive( ) is compiled as dc.w $0004,-1 with this, program hands OR screen is corrupted if i try with dc.w $0004,2 spr[x].active == 2 so settings the value is not a problem For some reasons, disabling the sprites from within the GPU is bad thing.... any idea @matmook @CyranoJ ? without this, I'll need to remove rmotion scripts ps: 4AM -> time to sleep...enough debug for today! Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted October 9 Share Posted October 9 No idea, RMOTION was added by Matmook and I've been considering removing it to create space for more GPU raptor functions. Quote Link to comment Share on other sites More sharing options...
KanedaFr Posted October 9 Author Share Posted October 9 Ok, so sadly, I should go without rmotion .... let's go for update loop Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted October 9 Share Posted October 9 54 minutes ago, KanedaFr said: Ok, so sadly, I should go without rmotion .... let's go for update loop You can use it "as is" for now, but it'll pass into "legacy" builds going forward. Quote Link to comment Share on other sites More sharing options...
matmook Posted October 9 Share Posted October 9 17 hours ago, CyranoJ said: No idea, RMOTION was added by Matmook and I've been considering removing it to create space for more GPU raptor functions. If it's not used at all (but by KanedaFr), that's the way to go. 1 Quote Link to comment Share on other sites More sharing options...
KanedaFr Posted October 9 Author Share Posted October 9 18 hours ago, CyranoJ said: to create space for more GPU raptor functions. This made me re-read Jaguar tech ref and some threads here on AA, like this awesome one: I realized I made the error to think a Jaguar game is a 68K-based game (or at least how easier it is to make it 68K based) I'm on Jaguar Dev world for 2 weeks only so please, be kind with me So, can you help me to confirm if I understood or not ? - rMotion compile scripts to RISC code, JagStudio/Raptor load this code on the GPU and GPU runs it in parallel on the 68K code, right ? - Since the 68K should only be used as a manager, coding the animations on the 68K side is not the way to do, right ? - if animation is controlled by the 68K, I limit the number of sprites I could handle on my game, right ? - Using JagStudio/Raptor, I have no view on what happen on GPU side so it's not possible to code RISC animation and offloading (?) it to the GPU, right ? or is setting the RAPTOR_LIST sprites properties some kind of magic with a link to the GPU ? This quote from @CyranoJ is what I call magic Quote as long as RAPTOR is doing the animations and movement, as all that happens automagically in the GPU core. I'm looking for the right way to do it and to learn more and more about the Jaguar so any hint is welcome ! Thanks Quote Link to comment Share on other sites More sharing options...
sjc Posted October 10 Share Posted October 10 I'm also new at this, but I think the best thing to do for now is not to over-think or worry about it. Especially if you're using JagStudio, which uses the GPU to do the heavy lifting for you, while your game logic runs on the 68k. There's generally quite a bit of headroom before you run into performance issues. Sorry I can't offer any help on rMotion. Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted October 10 Share Posted October 10 10 hours ago, KanedaFr said: So, can you help me to confirm if I understood or not ? - rMotion compile scripts to RISC code, JagStudio/Raptor load this code on the GPU and GPU runs it in parallel on the 68K code, right ? - Since the 68K should only be used as a manager, coding the animations on the 68K side is not the way to do, right ? - if animation is controlled by the 68K, I limit the number of sprites I could handle on my game, right ? - Using JagStudio/Raptor, I have no view on what happen on GPU side so it's not possible to code RISC animation and offloading (?) it to the GPU, right ? or is setting the RAPTOR_LIST sprites properties some kind of magic with a link to the GPU ? This quote from @CyranoJ is what I call magic The polite answer will take more time than I currently have. If nobody has responded by next week, and I still remember (or can be bothered...) I'll do it then. The impolite answer is RTFM and look at the examples. 1 Quote Link to comment Share on other sites More sharing options...
KanedaFr Posted October 10 Author Share Posted October 10 (edited) 28 minutes ago, CyranoJ said: The impolite answer is RTFM and look at the examples. 🤕 To understand how this works natively -> Jaguar doc, of course...It's not easy to understand but I think I have the main picture, it's why I ask how it should be handled with JagStudio To understand how it works under the hood with JagStudio/Raptor -> I read the doc / examples, browsed the generated build file but , unless I probably missed something, I didn't find details... I have some hints on the deprecated Raptor API doc but not much Edited October 10 by KanedaFr Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.