Best method for tile maps in Blitz2

[htdreams]

Hi there!

I'm developing a game using Blitz2 with an Amiga 600 (2mb and hd, although that is not important for this question )

Currently i'm getting the grip on Blitz programming, i have the official manual and reference guide, and i try to search this questions in google but, at least for now, without success.

I'm making an adventure game, but not the kind of games like Sierra or Lucas ones, it will be more arcade like, something between Where Time Stood Still and Zelda games...

The fact is that before starting up the game itself i'm learning how to do several things, so i can design the gameplay and game elements and graphics knowing what kind of limits i have (this is very different to using unity 3D )

For now i'm focused on getting a player controlled sprite walking around in a tiled map with smooth 8-way scrolling and collision detection.

I'm trying to have a big map (a 255x255 byte array) with a tile map, and i use getashape to get 16x16 tiles from an iff image, and then use block inside a double for loop to put the map section the player is in into the two bitmaps wich are used for double buffering

My question is, is there a better known method?

What is the shape number limit? can i have more than 255 shapes? i would use them for all soft sprite frames and all tiles (i'm using near 30 shapes for now)

Can i use blockscroll with the same bitpmap to scroll all tiles to the right, for example, to put only new one column of tiles in the bitmap and use that to get smooth scrolling with a bitmap a bit larger than the screen?

I'm using Block to blit my tiles, but that way i must use shapes, as block works with shapes... i was thinking about it, and may be i need to use another method to copy tiles from tile library bitmap and then do a full blockscroll...

Is there a way to use block with bitmaps instead of shapes?

Hope there are someone that could light me the way to go...

[BippyM]

How are you generating the display?

Is the whole map rendered on various screens that you then scroll??

[htdreams]

Hi!

This is what i have for now, i'll put some lines of code, not the entire source, as i try another things aside from tile map scrolling :-)

; my two main bitmaps
BitMap 0, 480, 416, 4 ; doble buffer 1
BitMap 1, 480, 416, 4 ; doble buffer 2

; my screen mode
Slice 0, 44, 320, 256, $fff8, 4, 8, 32, 480, 480

; my tile grabbing section (i use an iff image with all 16x16 tiles), i have
; first 24 shapes for soft sprites
Use BitMap 4
i=0
For y=0 To 2
For x=0 To 19
GetaShape 24 + i,x LSL 4,y LSL 4,16,16
i = i + 1
Next
Next

; my map, and the loading bit, i use map editor "tiled" for mac/pc and
; save the file as json, later i convert it to binary with a tool i made
; with lazarus (free delphi clone)
If ReadFile(0,"desierto3.map")
ReadMem 0,&maxmapax.b,1 ; width in tiles
ReadMem 0,&maxmapay.b,1 ; height in tiles
maxmapax = maxmapax - 1
maxmapay = maxmapay - 1
Dim mapa.b(maxmapax,maxmapay)
ReadMem 0,&mapa.b(0,0),(maxmapax+1)*(maxmapay+1)
CloseFile 0
End if

; main loop, currently i have only a gosub to update scx and scy vars
Repeat
VWait
Show db, scx,scy
db = 1 - db
; updatebackground is a flag to allow for doublebuffer replication
If updatebackground Then Gosub clonebackground
; now i call a subroutine to detect key strokes to move the screen
; left - right - top - bottom, so if i update scx and scy and if i reach
; the bitmap border i call drawmap to update bitmaps with new
; map tiles
Gosub moveScroll
Until RawStatus($45)

.drawmap:
; for now i repaint the entire bitmap, here i want to use blockscroll to move
; all tiles to the final position, and then add only new columns/rows
Use BitMap db
FlushBuffer db
For y=0 To 25
For x=0 To 29
Block 24+mapa(startx + x,starty + y),x LSL 4,y LSL 4
Next
Next
updatebackground = 1
Return

.clonebackground:
CopyBitMap 1 - db,db
updatebackground = 0
Return

-----

It's very basic (errr... lol?) code...

[leathered]

Looks good to me. I love the fact that you're reading the map from binary and using LSL to designate the blocks positions.
I know of 3 main ways to scroll a map:
block scrolling; updates a block at a time
fine scrolling; copies a section of the screen
hardware scrolling; offsets the current display viewport

You won't get it any smoother than hardware scrolling, and whilst there are a number of considerations it shouldn't (in theory) be much harder to do than the other ways in Blitz. You will also gain considerable speed if you 'clip/buffer' the screen using a fine scroller. And it should enable you to draw massive maps using the hardware scroll (in theory!).
A little reading material I found interesting a short time ago-
http://http://eab.abime.net/showthread.php?t=59345
http://http://eab.abime.net/showthread.php?t=20499&page=2
http://http://www.codetapper.com/amiga/interviews/chris-sorrell/
AFAIK the number of shapes is limited only by memory, I'm currently using almost 200 at 64*100 pixels.

I think the main thing is just to keep developing what you've got, and to post it on here when you get somewhere!

[htdreams]

Thanks for your valuable info, Lielo :-D !!

This will be a very busy weekend, but i'll try to put some of this reading in practice and i'll post results :-)

Things like working with binary files and doing LSL operations comes to me as a nice retro touch from my demoscene old days (although i was developing it in PC computers by the time...)

Nowadays there is to much script & .NET programming in everyday work :-P

So crunching some code in old machines gets more refreshing than playing modern games... X-DDD

[htdreams]

Ok, i have now a 8-way map scrolling demo, using doublebuffer with two 352x288 bitmaps (1 tile offset screen in each direction).

I'm using blockscroll to move all the tiles to the opposite scroll direction and then copy with blockscroll a new row/column (i draw two tiles in each frame to a bitmap, to be able later to dump an entire row/column in one blockscroll command)

I'll put a demo and the source code for all i have for now (must discard some tryouts and comment a little)

But the two main problem i face are:

- Blockscroll is buggy when moving downwards: when i go up and do scroll the main view goes down, that blockscroll comand only draws first 16 height row, and then repeats that 16 pixels height row for all the screen. If i use Scroll instead of BlockScroll it works, but it's supposed more slow...
- I feel it's not fast enough, currently i have only the scrolling thing and nothing more, can't see this with several sprites running around, music, sound effects and game logic going on...

Here i put the demo i made, so you can try it:
http://www.proyecto-iris.com/files/a..._8way_demo.zip
It's just a test, so here are the controls:
W-A-S-D move the map (diagonal scrolling has some bug, i don't care, i know how to fix it)
TAB change between using blockscroll / scroll statements scrolling up (the rest are using blockscroll)
SPACE reset view to start again
ESC ape? :-)

What do you think?

Is there a way to get current processor tics or some value to measure how much time takes to do stuff?

[leathered]

Gave your demo a try. Aside from the bug you mentioned it looks to be coming along. The other slight issue is the slight pause that appears to happen when you are 'buffering' the new sections. Whether it's really a problem or not depends on the style of game, I would say right now that it isn't but as you said it will depend on how things run with other elements of the game engine in there. My old Atari ST would have loved scrolling this smooth.

To clarify my earlier post – a 'block scroller' is actually called a 'course scroller', and would appear very jerky, updating 16pixels at a time. Along the terms described in this post you have developed a 'fine scroller'. Although this term is also used to describe the quality of smooth scrolling associated with hardware scrolling it seems. I'm relating to them in the manner in which I learned so I hope not to confuse. I was trying to define the difference between using hardware registers to scroll the screen and blitting in the sections in a new position.

To measure how much time a piece of code is taking you can change the colour registers for the background for individual sections. You can also change the colour registers to change if the frame takes longer than than 1 or 2 vbl to update using interrupt 5. http://eab.abime.net/showthread.php?t=62286

I'm not sure if you've used hardware scrolling before, but to do so is initially as simple as using 'display bitmap' and updating the co-ordinates it is to be repositioned at. The more complicated part is updating your map to fit the scrolling as it's a different procedure from the other ways.

I can't really talk, as compared to all this effort I feel I'm cheating! My current project sacrifices everything for speed including memory when it comes to bitmap size. I'm using a similar technique as in the James Pond game and simply hardware scroll a large bitmap. I'm well aware that may have to change but live on in ignorant bliss...

[Samurai_Crow]

There is a very articulate description on the Aminet of how to do hardware-scrolling. It's at http://aminet.net/package/dev/src/ScrollingTrick but it lists its source code in C. The descriptions of how to access the hardware using the fewest blits possible while scrolling is excellent. Also of note, Georg is now an AROS developer and has released ScrollingTrick's license and now considers it public domain.

[leathered]

Put an archive in the Zone for you, forgot I had this on my HD. Another 8 way scrolling example which is less complete than the example provided above. It's in ASM, and the readme file is (unusually) informative.
I think you should be happy with your work so far, it's really good. If you do carry on developing using the blitz blockscroll command it will be faster and should have less of a performance hit with more going on. You can just about notice the difference already. Perhaps you could try mixing the scroll command with blockscroll or block to buffer the tiles? Anyway, good luck with it!
If you are using block you can invoke the blitz commands directly having stored your variables in the data registers like so:

getreg d0,block image
getreg d1,x
getreg d2,y
tokejsr block

This saves blitz from having to shuffle your data around and should be faster although I've yet to run any benchmarks. I expect all it really saves is a bit of processor work but it's worth considering if your game gets busy.

Ok I found where I got the archive from @ http://www.blitz-2000.co.uk/ - under archives/blitz mode source

[htdreams]

Thanks for the info you two :-)

The interrupt method for measuring time progress is a good idea, i'll use it (i know it's not the perfect one, but it'll fit my needs)

As for the method in the code linked by samurai_crow, i downloaded it, but i need time to understand before translating it to blitz, guess i'll try first the method from Lielo :-)

I'm busy atm but as soon as i have spare time i'll try it and post my results with code, to be useable for others as well.

Thanks!

[Raislin77it]

any news htdreams?
i'm really interested in the scrolling thing

[htdreams]

I'm afraid i have no news for now, i can't gather enough spare time for now, at least for this month.

Currently i have two working lines:

1º My current goal is to get a workin 8way smooth scrolling fullscreen in 320x256x16 colors without dualplayfield (so background and software sprites will share palette). Here i must learn by examples how to do it using asm with blitz.

2º Try the same example i have now with dualplay fields, that means having only 8 colors for background and 7 for software sprites, but it's supposed to be faster, and i think i could have the demo working with little time.

Another thing is the problem with blockscroll when doing movements upwards, as for that i have to use scroll wich is supposedly slower. I found some guy with same problem in blitz bbs messages from august-1995 but nobody replied him and i have no more info until 1998 (i'm slowly reading every Bliztlist bbs post).

I'll update this thread as soon as i get something new :-)

[diablothe2nd]

I'm keen to see how you get on with this also, as i'm currently working my way through learning Blitz. So far I have a simple text based Roulette game just to learn some of the math and program flow but I have an idea for a game that is top down isometric with 8 direction scrolling

i'm curious to know what Blitz version you're using? perhaps this bug was fixed in AmiBlitz? I've gotta say I much prefer TED from AmiBlitz than the old TED but apparently it's not so nice with non-expanded amigas (great on an 060 or UAE though!)

[htdreams]

Hi!

I'm currently programming in an A600 with 2 meg. chip ram, so can't use amiblitz for now, as it ask for fpu, i'm using Blitz 2.1.

I'm in the process of "upgrading" to a 1200 so then i could use better tools. Does amiblitz allow building games for a500? that's my target computer, may be next game could be done for AGA machines (i know that with AGA programming i could better things, in fact, 1200 machines are faster than old 68000 ones )

[diablothe2nd]

Originally Posted by htdreams

Does amiblitz allow building games for a500?

if you follow the relevant palette limitations of OCS/ECS then I don't see why not. obviously if you're making a game for an A500 on a 1200 then there will be differences in speed due to the processor.

I think it only needs the FPU for compiling but the end result should be good for whatever you set your target to be.

[Coagulus]

When I used Amiblitz for a bit my compiled game (Timebomb) didn't work on Kick 1.3 A500s so I switched back to 2.1

[diablothe2nd]

i'm guessing you were calling a library that ks1.3 didn't have?

[BippyM]

Or it was allocating too much ram, or a miriad of other issues!

[Coagulus]

Originally Posted by diablothe2nd

i'm guessing you were calling a library that ks1.3 didn't have?

Yeah, that's what I was thinking, the exact same code compiled and ran fine on A500 in 2.1 though. So I just stick with that now.

[edit] ah, I mean Blitz 2.1 not Kick mind!

[leathered]

Hi htdreams. Decided to delete my last post as it may help your thread continue and the method used there doesn't even work with the debugger on. I've felt in danger of sabotaging your thread. Hope you're still working away with your project when you can. Would be good to see the results in a game. Take care mate.