New Probs :(

I have a picture Box that contains a picture (of course!)
approximatly 600 x 1000 pixels

Everything work fine until I use the PaintPicture to resize the picture. Upto 5 times the size of the original pict, everything is fine, and all of the pictures is shown. When I try to resize it 8 times or more of it's original size, only the right half of the pictures is viewable. (I scroll the picture to see the whole of it).

The other half show nothing (the background color of the picture box is shown) and the pictures is cut in the middle.


In other term you can Imagine something like the picture box size is the size (height and width) of the large picture but the left half of the picture is missing when it should display it!

Other Facts: When I load an Icon (32x32 pixels) and I resize it 10 times, it is show correctly in the picture box.

Is there something about the Maximum width and height of the picture box? (I've tchek these and the values was: x = 10350 twips per 12500 twips).

or Not enough memory?

No error is generate when I call picturebox.paintpicture(...)

So what's the prob?

Well it's how many bytes of memory are used in your picture, for a 4800x8000 picture (lets say at 24 bit colour depth) that's this many bytes:

4800x8000x3 = 115200000 bytes = 112500 kilobytes = 110 megabytes :o

Which is really bad, you can't have pictures this big, really!

As an addition, even if you have 128 megs of memory some (20 megs maybe) will have already been taken up. And once you show that picture you will have absolutely no memory left.

As a refrence, 7x works because it is only 85 megs. But seriously you cannot even have pictures this big. As a self-regulation, I have images that are no larger than 1/4 of the screen size (400x300 for 800x600, etc). If I need something bigger I usually just quarter it like in this case, if I needed a backdrop...

But of course that's for games... Is that what this is for or are you doing some sort of exercise?

Yeah, I haven't in mind the quantity of ram needed, it may be the prob (well at 99.99 % ;) )

Im making a small program to extract tiles from any pictures, of course with more options than that.

I'm a bit shame for posting this msg, I should have known!

Well if it's for tiles why don't you create a 'tile file' based on different images, etc...

Maybe giving the file a layout such as X/Y/FileName/TileName

0/0/file1.bmp/Wood1
0/0/file2.bmp/Wood2
32/0/file1.bmp/Grass1
32/0/file2.bmp/Grass2
0/32/file1.bmp/Water1
0/32/file2.bmp/Water2

Sas, you can have pics over 110MB
My art design map has a dozen of BMP (&PSD's) that are almost 200MB+ ... though they are 12048x2048x32 :)

(no... 12048x2048 aint a typo :P)

I've found the real problem, and of course solved it :)

First:
Only the viewable part of the image is loaded in memory (plus the real one that haven't got any modifications) so there's no 3000x2000 (pixels) pictures in memory when I resize them.

Second:
Only the left half was viewable when resized.

Where was the prob?
Me and the method PaintPicture from a PictureBox.
Let's say we have a 100x100 pixels picture. The starting point (top left) of the selected rectangle (to copy that picture zone) in the picture is 99 (in x) and 99 (and y). So if you decide the width and height will be 25 pixels, you'll go off "pictures" by 24 pixels (99 + 25 = 124 - 100 = 24 pixels to far). So when you call PaintPicture with theses "extra" width and height, PainPicture doesn't tchek the values and copy what ever it found. So when the first right half was missing, it was in fact the "extra" width and height of the original picture, that was of course, nothing. Thus it was overwriting my picture left half side with "Nothing".

How to solve it:
Calculate the appropriate value and tchek if it doesn't go outside range of what you want.

What Was funny (and I don't understand it even now) is that was working correctly for smaller resize... odd, I think it should have behave the same way for all resize type...

Sastraxi, it's a good idea what you have mention earlier. But it may be only a future option (which is really interesting I must say :) )

The main purpose of this program, is to be able to Extract tiles from any pictures (and the easiest way possible for the user). Suppose you love like hell Final Fantasy games and you want tiles from that game, well you take the screen shot of the place where the tiles appears and then you launch my prog to extract from the pictures the tiles.

Of course a lot of options is under development right now, but it's the main idea.


When it will be finish I will probably give it on my future web site ;)

I'm was working on a mini-RPG, it's just about 1 hr of play.. if you get the chance to make a file format for the tiles don't hesitate to post it here, as I may be able to update it as my method of storing tiles is bad in 3 ways - speed, memory, and size !

No thats how much MEMORY they take up.. you see you cant load the whole picture (rather you SHOULDNT) as it'll take up all your memory.

Maybe I've mislead myself the way I explain how my prog works.

The pictures that's 10 times is size is not loaded in memory. Only the viewable part of it is shown thus loaded, the rest is not there (in memory). When you move the picture, it's coordonates are re-calculate from the original to get the correct part to show on screen.

It would be a shame to have a 10 times pictures size in memory ;)

You're working on an Rpg! :)

Would it be possible to have a compile version (or the source I don't care) to be able to see what you've done?

Are you the "All" Designer of that game?




For the Tiles Storing Files, my first though was to leave that to the user once it have finish to extract Tiles from it's pictures (im .bmp), but It would be nice to have all tiles into a "package - effiency to load"

Would it be possible to see how did you make up your storing algorythm for tiles storing? (The one you mention that lack of speed, size and etc?)

Anyway meanwhile my day, I'll think about some way to have a tiles files base and how to do it efficacely.

Hum shouldn't you have the Autoredraw property set to True? :rolleyes: :D

Well I was and never got the tiles correct.. it was a fullscreen DDraw app ;). I had some animation going there, and my character moved, it had colour keys, and going at 600 fps ;). With tiles I suspect it may have gone close to 150, where it is with VSync on ;).

I'm not too experienced but I could share my trials and errors with you, I guess =).

Here is a link to what the game looked like... (note the message box particularly, that's VB/DX7 code): http://vbden.tripod.com/pics.htm

Here's a full pic of the character & his outfits (first 6 are originals (w/anime eyes though), last 6 are adapted to look like anime, note the thick black lines and the general lack of realism)

Storing algorithm eh what? Ah, that one ;)

It actually wasnt for this RPG, but one i made long ago. (in dos believe me or not!) Anyways, this was my first stab at game design...

So enough about that, what I did is open a 256-co. bitmap (with my 16x16 pics inside) that was in total 256x256. It was a relatively small file for what it held, 256 bitmaps. *grin*

So what I did was load it into an array (heard o' those?) and then displayed EVERY single tile at runtime (which was expected only in this case 'cause the whole map was only 1 screen). This proved to be very slow until i just modified the memory addresses, in which case it became playable (320x200 screen, 25 fps with the second method).

The array was very bulky for such a small map, and it was difficult to do much in a small period of time, which is why I like DirectDraw ;).

So anyways what I was going to try doing this time was to still have an array, but have a fast array for where i was, using copymemory to get the array variables I wanted, this was perfect using UDTs. So I use a UDT with TileSetHandle, TileSetX, TileSetY, Passable, Index.

Index is for special events (triggers specify an index, which is a linear long integer for obvious purposes). Passable indicates whether you can pass, TilesetX is the X offset on the TileSet (* 16 for tile's width). TileSetY is the Y offset ( * 16 again ).

TileSetHandle is what tileset it comes from.... and then there were some global variables like TileScrollX, TileScrollY, MapIndex, etc. There were 3 dimensions in this array; MapIndex, X, and Y. You can think of it as a cube sliced up lengthwise to get several finite planes.

I never got to use this because I had a funny little idea called Times of War =) but I urge you to try it and good luck. Ah yes another misc. tip for RPGs is for collision detection, make a mask that is white and has a black bounding box where the edges of the soles of his feet are. This will make sure that you dont stop prematurely when you come in contact with walls, and you can define it as a RECT and use Intersect Rect with it, very useful stuff!

Also you could opt not to use RECTs and do pixel collision detection which is very fast in DDraw *snicker, snicker*, to make pixel perfect collision, this is the method I'm trying. Try making a mask in the same way for every tile, and doing the pixel collision dectection on the collision tiles. This will come in very handy. Also Janus (you may have seen him around here as of late) has given me a graphics DLL that has some nifty 32-bit & 24-bit & 16-bit alpha functions for VB, I mean thats cool stuff !

However I'm still trying to make him give it to me :(

Well thats all for now I hope you didn't get too bored at my rantings.

Quote:

---

Ah yes another misc. tip for RPGs is for collision detection, make a mask that is white and has a black bounding box where the edges of the soles of his feet are. This will make sure that you dont stop prematurely when you come in contact with walls, and you can define it as a RECT and use Intersect Rect with it, very useful stuff!

---

Sorry, didn't get that one :confused:

Pixel collision detection may be fast in DX7, but circular collision detection is 1000 times faster and just a bit less accurate :D

What I mean is to have a black box (another 2d sprite) that is positioned where the soles of his feet are, and use that as a guide for where they can and can't go. It's best illustrated in this Zip, where 3 types are shown...

The reason i suggest a square is that it doesnt need to be accurate at all.

Heh, yeah, I had the same idea, where you'd have a circle for each foot, or one for both :)

Heh... did you like the sprite?

Yeah, did you make it? ;)

Yep ;) I made a whole slew of them...

look at http://vbden.tripod.com/ and then add clothing.gif to the end of it, making it http://vbden.tripod.com/clothing.gif (there's a remote loading policy)

Heh nice :)

What did you use to draw them?

Paint :D

Wow :D

I could draw something like that, but I'm just too lazy :) (Yeah, Paintbrush is very limited, I prefer Paint Shop Pro 7 :D ). It usually takes me 2 hours to make a good drawing like that using Paintbrush;)

Heh... really? It works wonders when you have your whole palette laid out on the monitor... :D.. It takes me about 30 minutes for a base image, 10 per new clothes, and maybe 15-20 total for an animation.

Oh and I suggest if you want to add full support for any game, add a function that loops through the pixels, finds exactly-the-same areas, and compares the two's location, so you can find how large the tiles are and how much they are offsetted (eg. if a 16x16 piece at 5,4 was the same as a 16x16 piece at 21,36 then you can tell the tile offset is 5,4 and the width/height is 16x16).

That's just a thought, but making something like that would prevent the user from having to manually select the position of any tile.

Hum... yeah, that's an idea ;)

I only take a lot of time because I'm a perfectionist :) It's not finished until it's 100% perfect :p

What are you talking about? I'm a perfectionist too :P
I'm all with the 100% deal

Ok... are you sure that all you used was MS Paintbrush, and it only took you 40 minutes? :rolleyes:

Yep, it's what I'm saying.