omf Posted December 22, 2015 Share Posted December 22, 2015 Just wondering if someone can give me some info or advice on this: In my Kaboom game I am getting a situation where I see various objects along the top of the screen for about a quarter of a second, these are the animation objects split into their individual parts so it appears to me what is happening is raptor splitting up the supplied image bmp’s into the animation frames for use. If this is the case can this be moved off screen so it isn’t seen? I haven’t seen this on any of the demo's or peoples games that they have made. Whether I have written a mess of bad code that’s clogging up the jaguars ‘powa’ I don’t know. But it’s definitely odd Can anyone give me any idea’s how I can fix or get around this I would be grateful Quote Link to comment Share on other sites More sharing options...
Sporadic Posted December 22, 2015 Share Posted December 22, 2015 Can't say i've noticed that happen before. The only case I can think of is where i manually changed the gfxbase and messed up the code and pointed to a wrong address. In that case, the sprite whos gfxbase i changed then might show various chunks of other sprites. Quote Link to comment Share on other sites More sharing options...
omf Posted December 22, 2015 Author Share Posted December 22, 2015 here's a video that shows this (most occurrences are missed due to the laggy capture method but a couple of instances are sown) and it shows a bug too, ill get on that vj.wmv Quote Link to comment Share on other sites More sharing options...
omf Posted December 22, 2015 Author Share Posted December 22, 2015 here's the binary I used for the video, run it and see what you think personally i think the issue is related to the sprite scaling of the explosion object which is quite large to begin with and in the game is is shrunk to quite small and the title screen it is increased to a massive size to fill the whole screen Kaboom.abs Quote Link to comment Share on other sites More sharing options...
sh3-rg Posted December 22, 2015 Share Posted December 22, 2015 (edited) Sprite scaling and screen edges is dangerous business - especially y=0 - magic Jaguar happenings are all too ready to piss on your parade,. Changing raptor list, also, can provide a single frame of weirdness - this is patched in the latest Raptor*, but is not in the latest rB+ AFAIK. *it's not a hard fix - you have to use a new command to prepare the new list before you switch to it. Edited December 22, 2015 by sh3-rg Quote Link to comment Share on other sites More sharing options...
omf Posted December 22, 2015 Author Share Posted December 22, 2015 Sprite scaling and screen edges is dangerous business - especially y=0 - magic Jaguar happenings are all too ready to piss on your parade,. Changing raptor list, also, can provide a single frame of weirdness - this is patched in the latest Raptor*, but is not in the latest rB+ AFAIK. *it's not a hard fix - you have to use a new command to prepare the new list before you switch to it. what about x=0? i have noticed a couple of things I can look into also with the object list im not changing lists maybe i need to? maybe i need to add objects of the right size and not scale? Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted December 22, 2015 Share Posted December 22, 2015 so it appears to me what is happening is raptor splitting up the supplied image bmp’s into the animation frames for use. RAPTOR doesn't work like that - without seeing the code I don't know what's going on, but it looks like it might be you've set gwidth incorrectly. Quote Link to comment Share on other sites More sharing options...
omf Posted December 23, 2015 Author Share Posted December 23, 2015 ok i have been at this most of the evening now and i have finally fixed it, firstly i quadriple tripple checked the object list for the explosion object. it was a corrupt image in the end after all that, just opened it in paint shop pro 7 and re saved it again and it was fixed! what's weird though is that I have not edited this image in quite some time so I didn't corrupt it myself so I can only assume dropbox causes damage some times during the sync process I have done a file compare on both the 'corrupt' version and the 'working version' in hex workshop and the only difference is two bytes in the bitmap header which windows obviously isn't bothered about and raptor / raptor basic is bothered about as I say the last time i edited the once working file was 24/11/2015 image attached Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted December 23, 2015 Share Posted December 23, 2015 Glad it's fixed ☺ Quote Link to comment Share on other sites More sharing options...
sh3-rg Posted December 23, 2015 Share Posted December 23, 2015 ok i have been at this most of the evening now and i have finally fixed it, firstly i quadriple tripple checked the object list for the explosion object. it was a corrupt image in the end after all that, just opened it in paint shop pro 7 and re saved it again and it was fixed! what's weird though is that I have not edited this image in quite some time so I didn't corrupt it myself so I can only assume dropbox causes damage some times during the sync process I have done a file compare on both the 'corrupt' version and the 'working version' in hex workshop and the only difference is two bytes in the bitmap header which windows obviously isn't bothered about and raptor / raptor basic is bothered about as I say the last time i edited the once working file was 24/11/2015 image attached Those are the x & y dimensions in the header. Quote Link to comment Share on other sites More sharing options...
omf Posted December 24, 2015 Author Share Posted December 24, 2015 well it looks like that wasn't totally my problem after all loading and saving the image in paint shop pro 7 fixes the explosion but when next compiled a different object gets corrupt. loading an saving the other object fixed that one and on next compile the explosion object is corrupted once again its always the same two one object is 16 bit 32x32 that is opaque and is actually a frame from the explosion animation resized, so it may be the graphics conversion after all ??? im going to try and reduce the explosion animation object size from 96x96 to something less i am also going to move it out of dropbox and try that too, just in case! Quote Link to comment Share on other sites More sharing options...
Sporadic Posted December 24, 2015 Share Posted December 24, 2015 Perhaps try deleting your build folder after fixing the graphic sizes ? Quote Link to comment Share on other sites More sharing options...
sh3-rg Posted December 24, 2015 Share Posted December 24, 2015 (edited) If your source gfx are being corrupted it's a local issue, rb+ doesn't mess with your original assets. Does your tool open the graphics as read only? Are you using multiple gfx editing tools and leaving files left open or write protected or something? I think it's your versioning techniques - dropbox/usb sticks/whatever - something is getting pwnt by an older version. Try changing your gfx to pictures of pikachu and nyancat. If the old explosions come back, you can shout at dropbox or whatever and come back and make a japanese-style "please understand" apology and bow before the rb+ massive or, as it's xmas and all that... Have you had too much RUM? Does the name "Jason Bourne" seem at all familiar? IS A THIRD PARTY EDITING YOUR CODE VIA THE COMPUTER INTERNETWORKS? Call 1-800-LOL-RUSH Edited December 24, 2015 by sh3-rg 1 Quote Link to comment Share on other sites More sharing options...
ggn Posted December 24, 2015 Share Posted December 24, 2015 Ok, sorry for the late reply, but after reading the thread a bit closer and discussing it over IRC let me try to explain rb+'s build process. When you invoke build.bat projectname assets are converted and a linkfile is created if we're building a ROM file. Also a few .inc/.h files are built so that the assets are accessible from Basic. At this stage assets.txt is read line by line and each asset is added to the mentioned inc/h/linkfile files. Also if there is some conversion needed (graphics, audio, etc) then it's also happening here. To save time converting the same files over and over, the converted files are placed into the project's build folder. Each time an asset has to be converted, the asset file's date is compared against the converted file's inside the build folder. Here we assume that if a file is modified (say, you open a bmp, edit it and save it back) it will have a newer time stamp than the one on the build folder. This will fail miserably if you copy an old version of the file in the assets folder! Also, another point of failure might be if you're working in different computers and the clocks are out of sync. I'm not sure how to deal with this as it's not something I thought about. Plus I'm certain that even build programs like GNU make suffer from the same problem. I could add a parameter to build.bat that deletes the cache if it helps? Quote Link to comment Share on other sites More sharing options...
omf Posted December 24, 2015 Author Share Posted December 24, 2015 Ok, sorry for the late reply, but after reading the thread a bit closer and discussing it over IRC let me try to explain rb+'s build process. When you invoke build.bat projectname assets are converted and a linkfile is created if we're building a ROM file. Also a few .inc/.h files are built so that the assets are accessible from Basic. At this stage assets.txt is read line by line and each asset is added to the mentioned inc/h/linkfile files. Also if there is some conversion needed (graphics, audio, etc) then it's also happening here. To save time converting the same files over and over, the converted files are placed into the project's build folder. Each time an asset has to be converted, the asset file's date is compared against the converted file's inside the build folder. Here we assume that if a file is modified (say, you open a bmp, edit it and save it back) it will have a newer time stamp than the one on the build folder. This will fail miserably if you copy an old version of the file in the assets folder! Also, another point of failure might be if you're working in different computers and the clocks are out of sync. I'm not sure how to deal with this as it's not something I thought about. Plus I'm certain that even build programs like GNU make suffer from the same problem. I could add a parameter to build.bat that deletes the cache if it helps? i would have brought it up in the irc channel but as its invite only at the moment i can no longer get in so had to post here im going to try to set the working asset to read only and try it then resave the bad one then set that to read only and see if that works i expect it is a dropbox issue so i'm going to try moving it out of there first i don't think deleting the build folder is going to help matters Quote Link to comment Share on other sites More sharing options...
sh3-rg Posted December 24, 2015 Share Posted December 24, 2015 i would have brought it up in the irc channel but as its invite only at the moment i can no longer get in so had to post here im going to try to set the working asset to read only and try it then resave the bad one then set that to read only and see if that works i expect it is a dropbox issue so i'm going to try moving it out of there first i don't think deleting the build folder is going to help matters Was invaded by dipshit script kiddies. Sorry you missed the info (it should be in your log!) - I'll PM you the access details. Quote Link to comment Share on other sites More sharing options...
omf Posted December 24, 2015 Author Share Posted December 24, 2015 If your source gfx are being corrupted it's a local issue, rb+ doesn't mess with your original assets. Does your tool open the graphics as read only? no Are you using multiple gfx editing tools and leaving files left open or write protected or something? no I think it's your versioning techniques - dropbox/usb sticks/whatever - something is getting pwnt by an older version. i have never used a usb stick Try changing your gfx to pictures of pikachu and nyancat.i will try this as a last resort If the old explosions come back, you can shout at dropbox or whatever and come back and make a japanese-style "please understand" apology and bow before the rb+ massive i just want to get to the bottom of the issue, i think rb+ is great it has enabled me to program something on the beast that is the jaguar all be it its not very fancy game but i am trying to fancy it up soewhat, but i had to start somewhere or, as it's xmas and all that... yeah, time off of work to bug find LOL Have you had too much RUM? no, i dont really drink much any more Does the name "Jason Bourne" seem at all familiar? nope IS A THIRD PARTY EDITING YOUR CODE VIA THE COMPUTER INTERNETWORKS? only myself from different computers LOL Call 1-800-LOL-RUSH considering how much help i gave him with his encription i would have hoped it would have been better 1 Quote Link to comment Share on other sites More sharing options...
EmOneGarand Posted February 24, 2016 Share Posted February 24, 2016 (edited) what about x=0? i have noticed a couple of things I can look into also with the object list im not changing lists maybe i need to? maybe i need to add objects of the right size and not scale? Sorry, not related to your problem but what is that GUI you're using in that screen cap? Edited February 24, 2016 by EmOneGarand Quote Link to comment Share on other sites More sharing options...
omf Posted February 24, 2016 Author Share Posted February 24, 2016 Sorry, not related to your problem but what is that GUI you're using in that screen cap? that program was written by my own hand, it is my raptor object list editor it can be found here:http://atariage.com/forums/topic/233057-raptor-list-designer/?p=3419456 Quote Link to comment Share on other sites More sharing options...
Welshworrier Posted February 24, 2016 Share Posted February 24, 2016 (edited) that program was written by my own hand, it is my raptor object list editor it can be found here:http://atariage.com/forums/topic/233057-raptor-list-designer/?p=3419456 Looking at the display could I suggest making the hex displays 16 bytes wide instead of 17 - I'd spent ages looking at the values before I realised why the offsets I was calculating were all wrong (that way all the embedded offsets will be easier to navigate) Edit: Just realised it was hex workshop in the PNG Edited February 24, 2016 by Welshworrier Quote Link to comment Share on other sites More sharing options...
omf Posted February 24, 2016 Author Share Posted February 24, 2016 Looking at the display could I suggest making the hex displays 16 bytes wide instead of 17 - I'd spent ages looking at the values before I realised why the offsets I was calculating were all wrong (that way all the embedded offsets will be easier to navigate) Edit: Just realised it was hex workshop in the PNG generally i would agree but i didnt see the need showing the difference of 4 bytes Quote Link to comment Share on other sites More sharing options...
sh3-rg Posted February 25, 2016 Share Posted February 25, 2016 generally i would agree but i didnt see the need showing the difference of 4 bytes You are not working towards your needs, but those of your customers :0) 1 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted February 25, 2016 Share Posted February 25, 2016 You are not working towards your needs, but those of your customers :0) As a professional software developer, that line makes me cringe so badly! It's like telling a cop he needs to piss off because you pay his salary 1 Quote Link to comment Share on other sites More sharing options...
Welshworrier Posted February 27, 2016 Share Posted February 27, 2016 (edited) generally i would agree but i didnt see the need showing the difference of 4 bytes It meant that you didn't have a one 2 one relationship between the vertical and horizontal scales and so when looking at the header descriptor for the bmps you couldn't just jump straight to 0x26 (for example), you ended up having to do 0x22 for second row and then use the 5th column for the data you needed - your xaxis values were not the actual lowest nibble values but offsets. If you had done it at 0x10 width then it would have mapped and been easier to see what the header offsets were as all docs tend to specify the byte offest e.g. https://en.wikipedia.org/wiki/BMP_file_format. As a result, you would have quickly seen that the xpixels per metre field and the ypixels were incorrect. It's not a criticism, just an observation that would have helped you get the answer quicker. Edited February 27, 2016 by Welshworrier Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.