Animation frames being displayed momentarily at the top of the screen?

[omf]

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

[+Sporadic]

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.

[omf]

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

[omf]

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

[sh3-rg]

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

[omf]

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?

[+CyranoJ]

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.

[omf]

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

 

[+CyranoJ]

Glad it's fixed ☺

[sh3-rg]

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.

[omf]

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!

[+Sporadic]

Perhaps try deleting your build folder after fixing the graphic sizes ?

[sh3-rg]

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

[ggn]

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?

[omf]

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

[sh3-rg]

 

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.

[omf]

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

[EmOneGarand]

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

[omf]

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

[Welshworrier]

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

[omf]

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

[sh3-rg]

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)

[+Stephen]

 

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

[Welshworrier]

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