Jump to content

Photo

Unpacking problems


14 replies to this topic

#1 Jeffrey_Bones OFFLINE  

Jeffrey_Bones

    Dragonstomper

  • 954 posts
  • Location:Charlotte, NC

Posted Tue Nov 21, 2017 9:30 PM

I'm now trying to utilize the powaunpack and I can't figure out what I'm doing wrong.

the background seems to be packing the way its supposed to but not unpacking when I want it to, which is right before the level starts when you press the OPTION key.

Here is what I get:

Attached File  powaunpack.PNG   169.94KB   1 downloads

 

To me this looks like the graphic is still packed and the unpack did not work, but I am not sure why.

 

Here is the startup code

            IF pad1=PAD_OPTION THEN
	    powaunpack ((int)strptr(SPRITE_LEVELA),(int)(int *)buffer)
	    rlist [0].gfxbase = (int)buffer                                         
            MODPLAY((int)strptr(MOD_HORROR))                         
	    hp=100
	    MODVOL(5)     
	    RSETOBJ(godead, R_sprite_active, R_is_inactive)
            RSETOBJ(fries, R_sprite_active, R_is_inactive)
			health=8
            chime2=1			
            RSETOBJ(title,R_sprite_y,-235<<16)
			RSETOBJ(title, R_sprite_active, R_is_inactive)
            RSETOBJ(copy,R_sprite_y,-235<<16)
			RSETOBJ(1, R_sprite_active, R_is_active)
            gamestart=1
			gametimer=0
 
            ENDIF	

	    IF pad1=PAD_OPTION AND gamestart=1 THEN	
	    RSETOBJ(godead, R_sprite_active, R_is_inactive)
            RSETOBJ(fries, R_sprite_active, R_is_active) 	
	    CALL SFX_gun
            RSETOBJ(crosshair, R_sprite_active, R_is_active)	
	    RSETOBJ(filtera, R_sprite_active, R_is_active)	
            RSETOBJ(p1scroller, R_sprite_active, R_is_active)       
	    RSETOBJ(menu,R_sprite_y,-235<<16)
	    RSETOBJ(menu, R_sprite_active, R_is_inactive)
	    RSETOBJ(copy, R_sprite_active, R_is_inactive)	
	    RSETOBJ(purplea, R_sprite_active, R_is_active)
	    foodtimer=9
            basic_r_indx=0
            basic_r_size=0
            countr=0
            dim sfxcount as short
	    RLOCATE 80,20
            PRINT "HEALTH  SCORE";score
	    RLOCATE 80,30
            PRINT "%";hp
	    RLOCATE 80,20
            PRINT "HEALTH  SCORE";score
            gamestart=1	
            health=8
	    hp=100
            slashtimer=500
            doubletrouble=0	
            ENDIF

I also have in DIM objects.

 

rlist=(RAPTOR_LIST *)strptr(RAPTOR_sprite_table)
                                                                  
DIM buffer[320*202*2/4] as integer                          

 

 

 

 

What am I doing wrong? Is this issue something to do with the score or am I just not using the unpack the correct way? The goal is to be able to pack all of the backgrounds and unpack them before starting the level to have more space for higher resolution zombies.

 

 

and yes in the asssets.txt file I have ABS,SPRITE_LEVELA,gfx_clut16_pack,ASSETS\GFX\levela.bmp

 

Please help. Thanks  :(



#2 LinkoVitch OFFLINE  

LinkoVitch

    River Patroller

  • 2,504 posts
  • Location:Manchester UK

Posted Wed Nov 22, 2017 6:05 AM

I have never used rb+ so I might be completely off here, I am assuming some of the conventions are C like...  In your listing.. is this correct:

rlist [0].gfxbase = (int)buffer

or should that be

rlist [0].gfxbase = (int)(int *)buffer

Or something similar?  I guess "buffer" is a pointer to the buffer? I am purely going off the way it is used as the destination of powaunpack



#3 ggn OFFLINE  

ggn

    Stargunner

  • 1,357 posts
  • Location:Athens, Greece

Posted Wed Nov 22, 2017 6:19 AM

So basically the crucial code to what you want to do is
 
DIM buffer[320*202*2/4] as integer    
rlist=(RAPTOR_LIST *)strptr(RAPTOR_sprite_table)
powaunpack ((int)strptr(SPRITE_LEVELA),(int)(int *)buffer)
rlist [0].gfxbase = (int)buffer
So, a couple of questions:

1. How do you know the file is packed?
a) Is it defined properly in assets.txt?
b) Do you see something like "Will attempt to pack <myfile.bmp.gfxdata>" on your build.log (hint: delete your build folder for a clean build if build.bat is skipping the file due to caching)
2. rlist[0].gfxbase will set the first object's gfxbase to whatever. Is that object your background object?
3. Is your packed file in ABS or ROM space?

Otherwise the code looks ok, matching most of project pack's code.


P.S. any objections in splitting this thread as this is another issue?
[EDIT FOR CLARITY] Topic has been split.

Edited by ggn, Wed Nov 22, 2017 3:37 PM.


#4 ggn OFFLINE  

ggn

    Stargunner

  • 1,357 posts
  • Location:Athens, Greece

Posted Wed Nov 22, 2017 6:21 AM

I have never used rb+ so I might be completely off here, I am assuming some of the conventions are C like...  In your listing.. is this correct:

rlist [0].gfxbase = (int)buffer
or should that be
rlist [0].gfxbase = (int)(int *)buffer
Or something similar?  I guess "buffer" is a pointer to the buffer? I am purely going off the way it is used as the destination of powaunpack


Actually this works - as shown in omf's pack example right here https://github.com/g...ck/pack.bas#L19. It is one of those rough edges of using a basic to C translator, the way variables and globals are exposed to the compiler which could be made better at some point.

#5 Jeffrey_Bones OFFLINE  

Jeffrey_Bones

    Dragonstomper

  • Topic Starter
  • 954 posts
  • Location:Charlotte, NC

Posted Wed Nov 22, 2017 2:20 PM

It did give a message in the log. I will need to run it again to tell you exactly what it said something about no graphic identified for unpacking. I will run again and get a screen grab. Be back in a few minutes


And no I dont object to the topic being split

 

 

 

Here it is:

 

Attached File  pack.PNG   57.5KB   1 downloads



#6 ggn OFFLINE  

ggn

    Stargunner

  • 1,357 posts
  • Location:Athens, Greece

Posted Wed Nov 22, 2017 3:37 PM

It did give a message in the log. I will need to run it again to tell you exactly what it said something about no graphic identified for unpacking. I will run again and get a screen grab. Be back in a few minutes


And no I dont object to the topic being split
 
 
 
Here it is:
 
attachicon.gifpack.PNG


Well, that's just a build error - looks like you copied this line verbatim to your source code. That one's wrapped inside a $comment/$comment block so that's actually a comment. You should remove this anyway.

But that's not what I'm after. If for example you delete the build folder in project pack and then build it again, you'll see the following in build.log:
 

Will attempt to pack c:\<your_path>\PROJECTS\pack\build\image.bmp.gfxdata
Command run: pack2e.exe "c:\<your_path>\PROJECTS\pack\build\image.bmp.gfxdata" "c:\svn\raptor\RA4AE9~1\PROJECTS\pack\build\image.bmp.gfxdata.pack"
Adding in RAM...


which says that it recognised that it has to pack something, and will run the packer. Finally it will import the file in RAM. Just need you to verify that this happens with your project so we can determine if the file is packed or not.

Also did you double check that object 0 is in fact the object you need to set gfxbase?

Edited by ggn, Wed Nov 22, 2017 3:38 PM.


#7 Jeffrey_Bones OFFLINE  

Jeffrey_Bones

    Dragonstomper

  • Topic Starter
  • 954 posts
  • Location:Charlotte, NC

Posted Wed Nov 22, 2017 4:12 PM

Ah! It is not object 0! Its actually object 3! That is probably the issue. I will see

#8 Jeffrey_Bones OFFLINE  

Jeffrey_Bones

    Dragonstomper

  • Topic Starter
  • 954 posts
  • Location:Charlotte, NC

Posted Wed Nov 22, 2017 5:29 PM

Attached File  unpack succes.PNG   158.32KB   1 downloads

 

SUCCESS!!!

 

Thank you ggn for helping me figure out what I was doing wrong!



#9 Jeffrey_Bones OFFLINE  

Jeffrey_Bones

    Dragonstomper

  • Topic Starter
  • 954 posts
  • Location:Charlotte, NC

Posted Wed Nov 22, 2017 5:44 PM

question does each object packed need its own DIM spot? like a bufferA with 32X64*2/4 and a bufferB with 16X48*2/4? like if they are different sizes shouldnt each one be in a different spot in DIM?

 

Also it looks like you don't have to put the object number in for unpack you can do it with object name as well, am I correct?



#10 Jeffrey_Bones OFFLINE  

Jeffrey_Bones

    Dragonstomper

  • Topic Starter
  • 954 posts
  • Location:Charlotte, NC

Posted Wed Nov 22, 2017 11:53 PM

of course I also see that it would be favorable to go by the object number a it makes the code shorter vs the object name



#11 Jeffrey_Bones OFFLINE  

Jeffrey_Bones

    Dragonstomper

  • Topic Starter
  • 954 posts
  • Location:Charlotte, NC

Posted Thu Nov 23, 2017 12:28 AM

Attached File  new code.PNG   27.37KB   1 downloads

 

This is what I have now and it is working like a charm for 4 packed images!!!!



#12 ggn OFFLINE  

ggn

    Stargunner

  • 1,357 posts
  • Location:Athens, Greece

Posted Thu Nov 23, 2017 1:15 AM

Ok, to summarise your questions a bit: (at least to the best of my understanding, feel free to correct me if I misinterpreted something)

1. powaunpack just takes a chunk of data and unpacks it into a space in RAM. Therefore you cannot unpack two things in the same RAM area (the one we DIM in the example) at the same time. On the other hand, if you want to have a single object which its graphics change with the level (let's say a background object) then you can unpack a different file without any other change. In the unpack example we DIMed a table just so we don't have to deal with memory management. If someone really wanted he/she could take memory management into their own hands and unpack directly into an address - however that is really really not recommended!
2. I'm a bit perplexed by your "you don't have to put the object number in for unpack" sentence. powaunpack doesn't care about objects at all - it just deals with raw RAM. I'm guessing you refer to the setting via rlist? If that's the case then let me remind everyone that rlist is functionally equivalent to rsetobject, but more fast. For example:
rlist[5].gfxbase=0x100
does exactly the same thing as
rsetobj(5,R_sprite_gfxbase,0x100)
Hope this helps clear things up a bit.

Edited by ggn, Thu Nov 23, 2017 1:17 AM.


#13 Jeffrey_Bones OFFLINE  

Jeffrey_Bones

    Dragonstomper

  • Topic Starter
  • 954 posts
  • Location:Charlotte, NC

Posted Sun Nov 26, 2017 12:16 AM

Can you only unpack once during a game loop? And when you do, does it unpack all of the graphics you have packed even if you aren't ready to use all of them? I wanted to unpack in sets of graphics. For example, unpack level 1 and then 2 characters, after thats over unpack level 2 and 2 more characters.

 

I would also like to know how to clear a sprite out of RAM completely.



#14 ggn OFFLINE  

ggn

    Stargunner

  • 1,357 posts
  • Location:Athens, Greece

Posted Sun Nov 26, 2017 1:48 AM

Can you only unpack once during a game loop? And when you do, does it unpack all of the graphics you have packed even if you aren't ready to use all of them? I wanted to unpack in sets of graphics. For example, unpack level 1 and then 2 characters, after thats over unpack level 2 and 2 more characters.


I'm not sure you got the hand of powaunpack yet. powanupack is a function like PRINT or RSETOBJ etc. You can freely call it everywhere you want as many times as you like within your source code.

So, to give an example, if you have a background as object 5 in your rapapp.s and your 5 games sprites as objects 6-10 you could do something like this:

dim background_buf[background_size] as integer
dim sprite1[sprite1_size] as integer
dim sprite2[sprite2_size] as integer
dim sprite3[sprite3_size] as integer
dim sprite4[sprite4_size] as integer
dim sprite5[sprite5_size] as integer

[...]

sub init_level_1
    for i=5 to 10
        rlist[i].y=500<<16
    next i
    powaunpack ((int)strptr(back_level1),(int)(int *)background_buf)
    powaunpack ((int)strptr(sprite1_level1),(int)(int *)sprite1_buf)
    powaunpack ((int)strptr(sprite2_level1),(int)(int *)sprite2_buf)
    powaunpack ((int)strptr(sprite3_level1),(int)(int *)sprite3_buf)
    powaunpack ((int)strptr(sprite4_level1),(int)(int *)sprite4_buf)
    powaunpack ((int)strptr(sprite5_level1),(int)(int *)sprite5_buf)
    for i=5 to 10
        rlist[i].y=0
    next i
end sub

sub init_level_2
    for i=5 to 10
        rlist[i].y=500<<16
    next i
    powaunpack ((int)strptr(back_level2),(int)(int *)background_buf)
    powaunpack ((int)strptr(sprite1_level2),(int)(int *)sprite1_buf)
    powaunpack ((int)strptr(sprite2_level2),(int)(int *)sprite2_buf)
    powaunpack ((int)strptr(sprite3_level2),(int)(int *)sprite3_buf)
    powaunpack ((int)strptr(sprite4_level2),(int)(int *)sprite4_buf)
    powaunpack ((int)strptr(sprite5_level2),(int)(int *)sprite5_buf)
    for i=5 to 10
        rlist[i].y=0
    next i
end sub
Then whenever you want to set up your level 1 stuff you just call init_level1. It will temporarily move the objects off screen so they won't flicker or show the depacking happening, then depack the data into the correct buffers, then bring them back to screen. Notice that the same buffers are used for both levels, no need to DIM new buffers if the sprites/backgrounds sizes' remain the same throughout the levels.

I would also like to know how to clear a sprite out of RAM completely.


You can use memset to clear ram. Have a look at the bcx manual for syntax.

#15 Jeffrey_Bones OFFLINE  

Jeffrey_Bones

    Dragonstomper

  • Topic Starter
  • 954 posts
  • Location:Charlotte, NC

Posted Sun Nov 26, 2017 2:12 AM

I'm not sure you got the hand of powaunpack yet. powanupack is a function like PRINT or RSETOBJ etc. You can freely call it everywhere you want as many times as you like within your source code.

So, to give an example, if you have a background as object 5 in your rapapp.s and your 5 games sprites as objects 6-10 you could do something like this:
 

dim background_buf[background_size] as integer
dim sprite1[sprite1_size] as integer
dim sprite2[sprite2_size] as integer
dim sprite3[sprite3_size] as integer
dim sprite4[sprite4_size] as integer
dim sprite5[sprite5_size] as integer

[...]

sub init_level_1
    for i=5 to 10
        rlist[i].y=500<<16
    next i
    powaunpack ((int)strptr(back_level1),(int)(int *)background_buf)
    powaunpack ((int)strptr(sprite1_level1),(int)(int *)sprite1_buf)
    powaunpack ((int)strptr(sprite2_level1),(int)(int *)sprite2_buf)
    powaunpack ((int)strptr(sprite3_level1),(int)(int *)sprite3_buf)
    powaunpack ((int)strptr(sprite4_level1),(int)(int *)sprite4_buf)
    powaunpack ((int)strptr(sprite5_level1),(int)(int *)sprite5_buf)
    for i=5 to 10
        rlist[i].y=0
    next i
end sub

sub init_level_2
    for i=5 to 10
        rlist[i].y=500<<16
    next i
    powaunpack ((int)strptr(back_level2),(int)(int *)background_buf)
    powaunpack ((int)strptr(sprite1_level2),(int)(int *)sprite1_buf)
    powaunpack ((int)strptr(sprite2_level2),(int)(int *)sprite2_buf)
    powaunpack ((int)strptr(sprite3_level2),(int)(int *)sprite3_buf)
    powaunpack ((int)strptr(sprite4_level2),(int)(int *)sprite4_buf)
    powaunpack ((int)strptr(sprite5_level2),(int)(int *)sprite5_buf)
    for i=5 to 10
        rlist[i].y=0
    next i
end sub
Then whenever you want to set up your level 1 stuff you just call init_level1. It will temporarily move the objects off screen so they won't flicker or show the depacking happening, then depack the data into the correct buffers, then bring them back to screen. Notice that the same buffers are used for both levels, no need to DIM new buffers if the sprites/backgrounds sizes' remain the same throughout the levels.


You can use memset to clear ram. Have a look at the bcx manual for syntax.

 

 

 

OK this makes sense, I haven't actually set up subroutines to change the levels yet. I was just doing the changes to the background in the main game loop based on triggered values. I probably need to set up subroutines similar to what you have in the example here. Also I already figured out you could use the same DIM as long as the 2 images were the same size (and I presume same bit/color depth?)

I'm going to give it a go making a subroutine.

 

thanks!





Reply to this topic



  


0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users