WAVE 1 GAMES Posted November 22, 2017 Share Posted November 22, 2017 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: 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 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted November 22, 2017 Share Posted November 22, 2017 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 Quote Link to comment Share on other sites More sharing options...
ggn Posted November 22, 2017 Share Posted November 22, 2017 (edited) 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 November 22, 2017 by ggn 1 Quote Link to comment Share on other sites More sharing options...
ggn Posted November 22, 2017 Share Posted November 22, 2017 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/ggnkua/bcx-basic-Jaguar/blob/master/projects/pack/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. 1 Quote Link to comment Share on other sites More sharing options...
WAVE 1 GAMES Posted November 22, 2017 Author Share Posted November 22, 2017 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 minutesAnd no I dont object to the topic being split Here it is: Quote Link to comment Share on other sites More sharing options...
ggn Posted November 22, 2017 Share Posted November 22, 2017 (edited) 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: pack.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 November 22, 2017 by ggn Quote Link to comment Share on other sites More sharing options...
WAVE 1 GAMES Posted November 22, 2017 Author Share Posted November 22, 2017 Ah! It is not object 0! Its actually object 3! That is probably the issue. I will see Quote Link to comment Share on other sites More sharing options...
WAVE 1 GAMES Posted November 22, 2017 Author Share Posted November 22, 2017 SUCCESS!!! Thank you ggn for helping me figure out what I was doing wrong! 2 Quote Link to comment Share on other sites More sharing options...
WAVE 1 GAMES Posted November 22, 2017 Author Share Posted November 22, 2017 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? Quote Link to comment Share on other sites More sharing options...
WAVE 1 GAMES Posted November 23, 2017 Author Share Posted November 23, 2017 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 Quote Link to comment Share on other sites More sharing options...
WAVE 1 GAMES Posted November 23, 2017 Author Share Posted November 23, 2017 This is what I have now and it is working like a charm for 4 packed images!!!! Quote Link to comment Share on other sites More sharing options...
ggn Posted November 23, 2017 Share Posted November 23, 2017 (edited) 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=0x100does exactly the same thing as rsetobj(5,R_sprite_gfxbase,0x100)Hope this helps clear things up a bit. Edited November 23, 2017 by ggn Quote Link to comment Share on other sites More sharing options...
WAVE 1 GAMES Posted November 26, 2017 Author Share Posted November 26, 2017 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. Quote Link to comment Share on other sites More sharing options...
ggn Posted November 26, 2017 Share Posted November 26, 2017 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. Quote Link to comment Share on other sites More sharing options...
WAVE 1 GAMES Posted November 26, 2017 Author Share Posted November 26, 2017 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! 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.