Sorry your browser is not supported!

I've made a working scrolling engine that refreshes the screen with 100X100 bitmap tiles from an array, but I want to sart over in 3-d. My game won't look very good with just sprites and pieces of bitmaps; I need the ghost-effect, which is unavailible for sprites, to make things look good.

My original approach was based on three bitmaps : the tilesheet, the "current portion" bitmap (1000X800), and the screen (800X600). A for-loop would fill the current-portion bitmap with tiles, copying positions from the tilesheet. In each step, an 800X600 piece of the "current portion" bitmap was copied to the screen.

When the variables xmove and ymove were 0, the loop would copy the central 800X600 portion of the "current bitmap" to the screen. If xmove or ymove equalled 99, the copying portion would be more towards the edge.

If xinc or yinc ever equalled or exceeded 100, the for-loop was used again, the "current bitmap" was refreshed from a different position on the world array, and xmove and ymove were reset to 0 (or something slightly bigger if either had actually ended up being greater than 100).

The scrolling engine was a bit more complex than this, but you get the idea.

However, I feel my approach to a side-scrolling game was inadequate. Pasted portions of bitmaps can't do very much, and they can only really be used with sprites. Ghost-transparency is impossible.

I want to rework the game so that textured plains are used for tiles, characters, projectiles, clouds going by under the tiles, etc.

There are different ways I could do this, and I need advice. I could use another "current portion" system, with a small grid of textured tiles over which a camera moved. Each time the camera overreached the current portion, it would be repositioned in the center and all the plains would be retextured according to the world array.

Or should I just create all the tiles for the whole world in the beginning? Would this overload video memory? (There would be up to 4000 textured plain tiles in existence, but only 80 or so would be visible at once).

How can I track how much video memory is being used by my game? Note that I would disable all collisions and lighting in this game.

About these textured plain tiles :

1. Could I disable all mipmapping and smoothing on these
textured tiles?

2. I would require about 100 separate images to be
textured onto these tiles. My manual says that all
textures should be 512X512! (would be some very huge
bitmaps to store). Why can't I use 96X96 images for
the plains? 96 is also a multiple of 8.

Sorry about asking all these questions - but I've been sticking primarily with bitmaps and sprites before now and I know little about these sort of things.

Well textures can be any multiple of 16 as far as I know. Anyway my Blockout game has blocks made from textured plains that are strange sizes like 26*32. Putting all of the tiles in the game in one go will just have to be tested by yourself. I would automatically remove tiles that scroll too far off the screen, it's up to you.

I think deleting offscreen tiles would be a good idea.

Still, what is so special about the number 512?

I want this game to be widely compatible. Is there any way, say by poygon counts or something, that I can determine how much video memory my game is using? Are loaded bitmaps included here?

There are commands to check the memory at any time, so I'd suggest looking into the DMEM AVAILABLE command etc, you can check physical and graphics memory - just check at the start then compare your results after loading everything.

One thing though, for your map, I'd suggest using 128 poly blocks of plains, like an 8x8 area, if you do that you probably wont need to do any fancy hiding or showing, it would run very nicely without optimisation - far faster than 2D methods. I could knock up an example for you, it's really just a flattened terrain with clever UV mapping.


Van-B

I'd like to know how to do that as well for my Monopoly board. I need to UV map the landing spaces individually to get rid of some bad z clipping of the individual squares.

DMEM AVAILABLE? I could really use that command. Is it not in DBpro?

I am basically doing what you said, Van B, and making a grid of plains that retexture themselves to simulate movement through a word. However, I have 96 different images I want to use. If every one of these images was 512X512 (the number they tell you to use for texture) then I'd have a ton of memory clogged up by some huge bitmaps.

Would 128X128 be okay, or will some video cards go faulty if I texture a plain with an image that is anything but 512X512?

Now that it's been brought up, I'm curious; what are the commands for checking used video memory?

Sorry, I just realized I spelled your name wrong, Van B. That's what happens when I look at the keyboard when I'm typing.

Glint,
The 512x512 is a strange one that I've never heard, but really you can disregards that. The important thing is to stick to power of 2 numbers, like 4, 8, 16, 32, 64, 128, 256, 512, and 1024.

Now for a neat system that won't clog your memory I suggest a single 1024x1024 image that is cut into sections, like if you set each tile to being a 64x64 image, you'd be able to use 256 different tiles - a lot more than you have now and a lower resolution - but with 1 big image it should be real fast.

Give it some thought, I reckon 1 big image is the best route for you.


Pincho,
I could make a board mesh for you, like with each square being a different limb that you could manually texture inside DB - It'd be quite cool to use images for the squares because you could let people skin their own boards, and themed monopoly is always cool. You'd need about 50 square images, but 50 isn't too bad really - I see no reason why it should'nt run smooth as melted butter.


Van-B

I used to be using a single tilesheet like what you've described above, but I figure that now that I'm using plains for tiles, (I have reasons for using plains, though its harder and slower) I should load each tile image as a separate image instead of using one huge bitmap.

Is there anything wrong with having a large number of images loaded? (Anywhere from 100 to 200).

How much memory can I safely use for images?

Are images stored in RAM or in video memory?

How much RAM does the operating system claim whiles you're running a game? (I know it must vary from operating system to operating system.)

Are images stored in RAM or in video memory? If nobody knows this, is there someone I can contact?

The truth is that nobody has ever had to worry about this. you have plenty of memory to make a game.

True, but I do want to know how to determine the required specs of my game in the event that I want to market it.