Loadanim Drawanim

Previous topic - Next topic

AndyH

A new update is available - boy do you work quick!

   // New Command:
   // LOADANIM, DRAWANIM - Tilesets solved internally

Thank you!!!  I'll start playing with these in the morning :)

All we need now is compatibility with SprColl and the rotation / scaling versions.  But thank you so much!!

Kitty Hello

sprcoll with rotation is so unusefully slow. If you really need it, draw/create some rotated images and load/grab these for collision response.

bigsofty

How about just letting LoadAnim just created a bunch of normal sprites, each with its own index, this would keep compatibility? Animation and referencing would just be left up to the user. Just a suggestion.
Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)

Kitty Hello

I will make a LOADTILES command which just makes a set of cut-out sprites for you. That was the way I wanted to go first. But it might be problematic when you have 1000 sprites already occupied.

bigsofty

That's fine by me.

I'm personally unsure if adding extra commands to the GLBasic command set that can already be done, with a little extra work, is a good thing though? I already had 'tilecut' and 'animatetile' functions written in GLBasic for example?
Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)

AndyH

I think the tilestrips are very useful.  I don't like the idea of having sprite numbers for my animations and writing wrappers around it to manage the sprite ranges.

Having both methods is a benefit to all, you can choose which way you do it.  I like the idea of a LOADTILES command too, but please do not loose LOADANIM and DRAWANIM..  

Btw, what I was meaning about the rotations and scaling was for the DRAWANIM to have the equivalents of ZOOMSTPRITE, STRETCHSPRITE, ROTOSPRITE and ROTOZOOMSPRITE.  To round it off we need SPRCOLL to support the frame number (or a command to do this eg ANIMCOLL id1,x1,y1,f1, id2,x2,y2,f2  where f1 and f2 are the frames and for sprites that have no anims (loaded with LOADSPRITE) you'd use the first frame as the paramter :)

kin

When it comes to huge levels it may be better if there is a way to tile the whole area with getpixel(a,b,c,d) and setpixel(a,b,c,d) and temporarily save/merge it as a single bitmap in a sprite? I don't know if this will slow down scrolling.. but I presume areas outside the window doesn't get rendered?

(a,b,c,d) = rect

I hope there is a way to tell glbasic to only render what's only visible in the window.

Kitty Hello

just do't use getpixel in any realtime process, ok.

Ian Price

Kin - that's rarely a good idea, due to problems with obtaining the value of pixels - each users machine's graphics card can cause uncertain results.

You are much better either using a map editor and loading/saving data or hard coding it into the core code. You know that the results will always be the same. Map editors and tile map systems are not difficult to write. I managed to get one up and running in under an hour having never used GLBasic properly before.
I came. I saw. I played.

kin

Well I've managed to load the data into an array first and read data from it realtime.
But I don't know how to save data(array) properly in a data file and read from it.

Ian Price

Here are the saving and loading functions from my current project. Each level is only one full screen wide (no scrolling) and each tile is 20x20 pixels, so I get a screen of 16x12 tiles.

All my data is stored in the map
  • [y] array and I store the data in Byte format, as the values of my tiles are not over 255 - this makes the resulting save file smaller. If you require more than 255 tiles, then use WriteWord etc.

"lvl" is a Global value, which is short for level.

Code (glbasic) Select
// Save data
FUNCTION save_data:

file$="data/"+lvl+".dat"

OPENFILE (1,file$,FALSE)

FOR y=0 TO 11
FOR x=0 TO 15
 WRITEBYTE 1,map[x][y]
NEXT
NEXT

CLOSEFILE 1

ENDFUNCTION
The loading function is almost identical
Code (glbasic) Select
// Load data
FUNCTION load_data:

file$="data/"+lvl+".dat"

// Check to see if the file exists
ok=DOESFILEEXIST(file$)

// If file exists, then load it
IF ok
 OPENFILE (1,file$,TRUE)

 FOR y=0 TO 11
 FOR x=0 TO 15
  READBYTE 1,map[x][y]
 NEXT
 NEXT

 CLOSEFILE 1

ENDIF

ENDFUNCTION
Simple. Although someone will probably come along now and show you an easier method. But these work for me and I'm happy with them :)
I came. I saw. I played.

Kitty Hello

Perfect. I'd save the width/height as WORDs first, so it's more flexible, but that's just peanuts.

kin

Ah guys you are great! It's very clear Thnx!! :)


Btw is there a limit in array? for example if you got list[2000][1500]
will this be inefficient and slow down?

Or is it better to open and read a section of code realtime when for example scrolling?

Kitty Hello

2000x1500 is quite big. Just a hint.
I had 100x100 in 2 games and the levels were huge.
You might get problems with loading single images that are bigger than 2048 on current hardware. Some cards even refuse 1024x1024, but they are really old.
So, I'd read in an array of less than 100x100 and have an intelligent tile drawing routine, that clips the non visible rows/columns in the first place.

kin

Ah ok. I'll try to let it read only a section in the datafile that's gonna be used for screen.

Is there an easy way to place for example B[10][10] next to A[10][10] and merge it to AB[20][10]
and write to datafile?

uhh..

Code (glbasic) Select
dim A[10][10]
dim B[10][10]
dim AB[20][10]

for y = 0 to 9
  for x1 = 0 to 9
    for x2 = 10 to 19
       AB[x1][y] = A[x1][y]
       AB[x2][y] = B[x1][y]
    next
  next
next
right?