I have problem blitting sprites

[Der Wanderer]

So, will take a while because I am busy.

The commands for Shape and Bitmaps are OCS/ECS/AGA compatible.
The Display commands are AGA only.

All I can see at this point is that I have never used the Display commands, but all others work fine, I have used this in the past a lot. So don't start doing workarounds for this, the problem is somewhere else, maybe the Display initialization. We'll see.

[A500]

Thank you so much

[Der Wanderer]

Your code doesnt work because of two things:

1. You declare a dual playfield display, this is why the colors are screwed up
2. You load your spritesheet into the visile bitmap 0. You need to load it into #2, and you should init it with 672x32x6, not 320x200x6.

here is some code that works:
[ab3]WBStartup

; flags for InitCopList
#smoothscroll = $10
#dualplayfield = $20
#halfbrite = $40
#ham = $80

#lores = $000
#hires = $100
#super = $200

#loressprites = $400
#hiressprites = $800
#supersprites = $c00

#fmode0 = $0000
#fmode1 = $1000
#fmode2 = $2000
#fmode3 = $3000

#agapal = $10000

#agalowres = #agapal|8


; Objects
#PALETTE_DISPLAY = 0

#BITMAP_DISPLAY = 0
#BITMAP_DISPLAY2_ = 1
#BITMAP_SPRITESHEET = 2

#SHAPE_DUMMY = 0

#BUFFER_BASE = 0
#BUFFER_BASE2_ = 1

#COPPERLIST_DISPLAY = 0

; Playfield specs
#PLAYFIELD_WIDTH = 320
#PLAYFIELD_HEIGHT = 200
#PLAYFIELD_DEPTH = 8

; Allocate Bitmaps
BitMap #BITMAP_DISPLAY , #PLAYFIELD_WIDTH, #PLAYFIELD_HEIGHT, #PLAYFIELD_DEPTH
BitMap #BITMAP_DISPLAY2_ , #PLAYFIELD_WIDTH, #PLAYFIELD_HEIGHT, #PLAYFIELD_DEPTH
BitMap #BITMAP_SPRITESHEET , 672, 32, 6

Buffer #BUFFER_BASE , 2*16384
Buffer #BUFFER_BASE2_,2*16384

; Load sprite sheet
LoadBitMap #BITMAP_SPRITESHEET, "robotstrip.iff",#PALETTE_DISPLAY
AutoCookie On
tile.w = 11
GetaShape #SHAPE_DUMMY,32*tile,0,32,32

; goto blitzmode
BLITZ

InitCopList #COPPERLIST_DISPLAY,44,#PLAYFIELD_HEIGHT,#agalowres,0,2^#PLAYFIELD_DEPTH,0
DisplayPalette #COPPERLIST_DISPLAY,#PALETTE_DISPLAY
CreateDisplay #COPPERLIST_DISPLAY
BlitMode CookieMode

db.w = 0 ; current buffer, 0 or 1
x.w = 0 ; x pos
y.w = 0 ; y pos

Repeat
VWait
x+xv : y+yv
If x>=#PLAYFIELD_WIDTH-ShapeWidth(#SHAPE_DUMMY) Then xv=-1
If x<= 0 Then xv=1
If y>=#PLAYFIELD_HEIGHT-ShapeHeight(#SHAPE_DUMMY) Then yv=-1
If y<= 0 Then yv=1

DisplayBitMap #COPPERLIST_DISPLAY,#BITMAP_DISPLAY+db
db=1-db
Use BitMap #BITMAP_DISPLAY+db
UnBuffer #BUFFER_BASE+db
BBlit #BUFFER_BASE+db, #SHAPE_DUMMY,x,y, Off
Until Joyb(0)

End[/ab3]

[A500]

Thank you so much it worked!! But I have just one question.....how do I change the sprite from a magnet that is pointing to the right to say another sprite from the sprite sheet where magnet is pointing up, or a robot sprite?

Ohh I discovered something else on it. If I keep it on for sometimes it crashes. As if it causes some memory leak or something.

Concerning how to switch between sprites I figured it out thanks As for the crashing, it happens only within AmiBlitz but if I run it from it's stand alone it stays there but when I quit it crashes. Must because I did not free the bitmap,etc. Thanks by the way! Now I can start working on my game again .

Here are the list of things I will be doing:

1) Make sure it checks the system have AGA and correct video output (PAL/NTSC)
2) Do a check if the file is in the same directory or otherwise display an error message
3) Build and complete the title screen 100% with the option for a level editor

When I finish the above conditions I will display the new .exe here so you can try it out. Then every time I progress more and I am happy with the result I will keep you posted here with a newer version to play with until it reaches beta stage then I will post the beta .exe program here. When the game is 100% finished I will release it with the source code to aminet Maybe in the future people like my game...they can improve on the graphics or game play.

[Der Wanderer]

Ohh I discovered something else on it. If I keep it on for sometimes it crashes. As if it causes some memory leak or something.

Works for me. Had it running for half an hour, and freed everything up to the last byte.
Did you use my code or did you change yours? I suspect you changed your code...
You need to take loop-invariant stuff out of the loop, e.g. cutting all the shapes.

Concerning how to switch between sprites I figured it out thanks As for the crashing, it happens only within AmiBlitz but if I run it from it's stand alone it stays there but when I quit it crashes. Must because I did not free the bitmap,etc. Thanks by the way! Now I can start working on my game again .

Probably you did it wrong, that's why it crashes. You don't have to free Blitz Objects, as I said in a post before. They are all auto-freed when you call "end". Also, if something throws you an error when running with Debugger from Amiblitz3, it will not magically work if compiled as executable. You will have the same bug, it just does not cause the machine to Guru immediately, but trashes memory and will produce all kinds of errors at a later time, often when resources are freed. That is why you run it with Debugger during development. The debugger is your friend ;-)

[A500]

I am going to compare again the code I have with your code written here just to make sure everything is working 100%. I will keep you posted on this regard. Now, I am trying to figure out how to animate the sprite with just two animation frame, then when I blit more of it into the screen how to make sure they are animating synch with each other and smoothly no matter how much of them I blit.

[A500]

I managed it correctly 100%. It is working 1000% now in terms of animation. I am able to put 60 objects animating spontaneously as the same time with the same speed. I have also written the foundation engine that allows it to read information from the disk or memory to display the sprites accordingly for the objects. Based on the value of the object the program now can determine whether to execute the animation subroutine or the non animation subroutine. I am going to send you the .exe today so you can see how it works.

[Der Wanderer]

Remember WinUAE is many time faster, on real classic AGA, you can have only about 10-20 such 32x32 objects at 50Hz, depending on the rest of the game logic.

[A500]

Remember WinUAE is many time faster, on real classic AGA, you can have only about 10-20 such 32x32 objects at 50Hz, depending on the rest of the game logic.

True. My game logic is going to be very simple, because the game is very simple. All you do is control the robot and put a box in front of the magnet. If all the magnet field is blocked you go to the next level. There are no monsters or AI in this game at all. You just need to make sure you have enough fuel to do it. There is a timer and fuel gauge and of course avoiding putting yourself in front of the magnet.

The game of course will have a level editor (as I will be using it to make my levels) and you go keep going to the next level until you reach to the end. Very simple. I guess the only logical AI that may put the game speed down is the magnets. You see...you get killed when you are in front of the magnet regardless of how far you are from it...so I guess there is what you cool a ray distance between you and the magnet. Maybe this will slow it down.

Of course ones the engine is 100% complete and running...I am going to show a video of it in the amiga.org community and ask for an entire replacement of the graphics I have to something much better than what I got.

[Der Wanderer]

Looks like then you are going to need only 2 or 3 (moving) Objects anyway.

I would not recommend you to write a level editor. This is too time consuming and probably slightly beyond your current programming skills. You should either define your levels as "data" sequences (or even binaries) in the source, or use a bitmap you can draw in a paint program. This is much (much) easier and faster.