A couple of questions

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|659\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Blitz -> A couple of questions
Sun, 28 Jun 2009, 04:10
Dither	Hi all, I'm working on a map editor for a tile-based game, using Blitz 2d. Some questions: 1) Is there a way for my program to "know" how many tiles are in a given image strip at the time of loading, without that information being hard coded? For instance, if my tiles will all be 32x32 pixels, and I'm loading in an image strip that's 64x32, it's a matter of simple arithmetic to take the total image width and divide it by the tile width, right? But I can't do this within LoadAnimImage, because the equation calls on the image handle that's being loaded. All I could come up with is to do a regular LoadImage for the tiles, then create a variable storing the ImageWidth value for the tiles. After that, do a LoadAnimImage using this "total_width" variable for my equation. There's probably a much better way of doing this, but in any case, it brought up another question... 2) How do I free up a chunk of memory that's no longer needed? Specifically, if I don't need a particular image after a certain point in my code, how do I free up that memory? Any help is much appreciated. Thanks!
Sun, 28 Jun 2009, 04:32
Jayenkai	1. Nope, that's the best way to do it, as far as I know.. I suppose you could technically read the raw data of the file, and try to figure out how to access the file's width and height. But.. You know.. Is it really worth doing it for a few millisec's at loading time? Sure, if you've a bundle of images, it might be, but.. shrugs 2. FreeImage YourImage -=-=- ''Load, Next List!''
Sun, 28 Jun 2009, 05:49
Afr0	In C# it would be relatively trivial to load a bitmap image and figure out it's width and height. I suggest if you're really set on going with Blitz2D for this, you write your own bitmap class. Or JPG or PNG class, depending on your needs. The format specifications for any of the most common image formats you'll might want to use are easily available through Google. Edit: Also, if you're thinking of coming up with your own format - KISS (Keep It Simple, Stupid)! Most Maxis/EA container/archive formats are made up of this format: Header String specifying the type of the archive (FAR, DBPF etc) Useless bit of info about the [date of] creation of the archive Useless bit of info about the [date of] modification of the archive Offset to the first entry in the archive (from the beginning of the file) Number of entries in the archive Entry Type of entry (may be some hexstring, bytecode or a combination of the two to identify a unique fileformat) (Filename of the entry) (Isn't always present) Unique ID of the entry (Should always be present so it can be used in place of filenames) Offset of the actual filedata from the beginning of the file Course, if you're going to add compression on top of this, it gets more complex, but if you overlook the actual compression code, all you really have to do is add a flag in each entry to specify if it's compressed or not -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
Sun, 28 Jun 2009, 06:22
Jayenkai	Take your own advice, afr0.. KISS You don't write your own bloody format for everything! Geeze, people, come on! This is how we ended up with 18,000 incompatible versions of Word, or a million versions of MSN protocol. Stop "fixing" things that aren't broken. Simply read what's there. .. sigh This isn't tested on all, but seems to work on standard .png images. DebugLog GetPngWidth("microbes.png") DebugLog GetPngHeight("microbes.png") Function GetPngWidth(filename$) quicky=ReadFile(filename$) Repeat in$=Right$(in,3)+Chr$(ReadByte(quicky)) Until in$="IHDR" Or Eof(quicky) back=ReadInt(quicky) width = ((back And $FF000000) Shr 24) + (((back And $FF0000) Shr 16) Shl 8) + (((back And $FF00) Shr 8) Shl 16) + (((back And $FF)) Shl 24) CloseFile quicky Return width End Function Function GetPngHeight(filename$) quicky=ReadFile(filename$) Repeat in$=Right$(in,3)+Chr$(ReadByte(quicky)) Until in$="IHDR" Or Eof(quicky) back=ReadInt(quicky) back=ReadInt(quicky) ; Use 2nd for Height ; switch from ABCD to DCBA height = ((back And $FF000000) Shr 24) + (((back And $FF0000) Shr 16) Shl 8) + (((back And $FF00) Shr 8) Shl 16) + (((back And $FF)) Shl 24) CloseFile quicky Return height End Function --v -=-=- ''Load, Next List!''
Sun, 28 Jun 2009, 07:08
Dither	Thanks for the help! I think I'll just stick with my original approach, seeing as how the editor is just a means to an end. And that other stuff is a bit over my head, honestly.
Sun, 28 Jun 2009, 10:24
JL235	I agree with Jay, but if you might want to try optimizing this in the future then I'd recommend wrapping the tile image and draw tile image into it's own functions. This way if you can think of better code in the future you only need to change those two functions! The rest of your code will be unchanged. However, disk IO is slow. Real slow. As you add more images to your game this will become noticable. At all costs I would try to ensure you only read the image once. No double loads and no opening it before hand to get the width/height. So if you use Jay's code above I'd recommend changing it to read both width and height together in one pass rather then two. Is there not some way you can read in an image, create an animated image and then draw the loaded image to the animated one? Otherwise it would be straight forward to load the image with LoadImage and store it's tile info in a custom AnimImage type (like width, number of tiles, number of tile rows, number of columns, size of tiles, etc). You can also create your custom draw anim image function that will just draw part of the image (I believe you can do this with the standard drawImage function).
Sun, 28 Jun 2009, 11:36
Dither	JL235, thanks for the reply. I'm not too worried about speed for this because it's just a map editor I'm using to create levels (not planning to distribute it). Within the game itself, I'll hard-code the numbers so I won't have to load the images twice.
Sun, 28 Jun 2009, 12:35
Jayenkai	I was tempted to put both into one function, but that'd require a global, and some people here tend to whinge about using Globals.. The other option would be to use a set of variables + a gosub, but.. wowie.. that'd cause a stir! -=-=- ''Load, Next List!''
Sun, 28 Jun 2009, 14:50
Afr0	Third option would be to use C# or C++, or maybe even possibly Java. -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
Sun, 28 Jun 2009, 15:09
Phoenix	Afr0, he's using Blitz, not C#, not C++, not Java, not language XYZ. And I think you're overreacting here JL, because from the looks of it he is only making a simple map editor loading a couple of images. I doubt that the disk IO performance hit will be significant. The idea of writing your own drawing function for images with frames isn't too bad though, and I suspect it would be easy using DrawImageRect. Jayenkai ...some people here tend to whinge about using Globals Well I hope you're not referring to me.
Sun, 28 Jun 2009, 19:22
JL235	I didn't realise it was for a map editor, so agreed. Performance isn't a priority. However I myself had to tackle a similar problem where I had to load images once to get their width and height and then load them again as a texture. It was incredibly slow. I then found out you can make textures using an image object and so switched to that (essentially I was now only reading the image once). It almost doubled the start-up time.
Mon, 29 Jun 2009, 12:30
Dither	The idea of writing your own drawing function for images with frames isn't too bad though, and I suspect it would be easy using DrawImageRect. Okay, I looked into DrawImageRect, and also DrawBlockRect. I understand how they work, and how they could be used for tiles and animation. But is there any advantage to writing my own function using these commands instead of just using Blitz's LoadAnimImage function?
Mon, 29 Jun 2009, 13:31
Phoenix	image = LoadImage("YourImage.png") Function DrawImageFrame(image, x, y, cellW, cellH, frame) width = ImageWidth(image) srcX = (cellW * frame) Mod width srcY = Floor(frame / (width / cellW)) * cellH DrawImageRect(image, x, y, srcX, srcY, cellW, cellH) End Function --v This will allow you to draw any frame of an image without knowing the amount of frames in the image, which I assume is what you're after.
Mon, 29 Jun 2009, 13:42
Dither	Phoenix, Sorry, I should have been more specific with my question. I meant, assuming I know the number of frames and don't have to worry about that particular problem, are there any other advantages to using DrawImageRect to display the cells from an image strip? Is it faster? But thanks for the code example. I'm going to study it and give it a try. Always learning something new here!
Mon, 29 Jun 2009, 13:45
Phoenix	I'll make an educated guess and say that they're pretty much equal. I haven't done any tests, but I really don't see why the difference would be anything but trivial.
Mon, 29 Jun 2009, 14:30
Afr0	Afr0, he's using Blitz, not C#, not C++, not Java, not language XYZ. I was merely pointing out a third option!! -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
Mon, 29 Jun 2009, 17:19
Mog	I'm tired of people suggesting other languages. It's the equiv of you going to get your car repaired, and someone saying DURHURRR YOU SHOULD BUY A HYBRID, IT'S BETTER. -=-=- I am Busy Mongoose - My Website Dev PC: AMD 8150-FX, 16gb Ram, GeForce GTX 680 2gb Current Project: Pyroxene
Mon, 29 Jun 2009, 20:06
JL235	Dither But is there any advantage to writing my own function using these commands instead of just using Blitz's LoadAnimImage function? It avoids having to load the image twice.
Tue, 30 Jun 2009, 12:15
Teasy	Jayenkai: Type SIZE Field Width Field Height End type Function GetSize.SIZE( file$ ) Local size.SIZE Local width, height size = New SIZE ; fetch dimensions .. width = .. height = .. ; fill object before transport size\Width = width size\Height = height Return size End function Function Example() Local size.SIZE Local framewidth, frameheight, numframes Local file$ Local image ; fetch dimensions file = "MyFile.PNG" size = GetSize( FileName ) ; determine division framewidth = .. size\Width .. frameheight = .. size\Height .. numframes = .. Delete pSize ; finally load image image = LoadAnimImage( file , framewidth,frameheight , 0,numframes ) Return image End function --v (no gosubs, globals, etc)
Tue, 30 Jun 2009, 14:54
Jayenkai	Yeah, but then you're creating/deleting a type, just for that purpose. If you're going to faff around with that, you might as well just use a couple of globals. That way, you're just using that one single bit of memory, and not going around adding and subtracting things all over the place. Coders are very messy nowadays. ... That's a WW Idea, right there.. -=-=- ''Load, Next List!''
Sat, 18 Jul 2009, 09:23
realtime	I like global. it makes me work faster and easier. What is so wrong with global anyway? -=-=- me blog: fork-garden
Sat, 18 Jul 2009, 11:10
JL235	There is nothing wrong with global variables, there is no reason why you shouldn't use them (and I have used global variables in recent code). However in my experience it will typically make your code more confusing then if you used the alternatives. Bear in mind it's a type variable that can be read from or written to anywhere in your program. If your program is 1,000 lines then it's not really an issue, but at just 10,000 lines (which in reality is quite small) using global variables can become very confusing. This is also compounded in a team where no one will know the entire code base. I've been given code where literally 20 to 30 global variables (all undocumented) needed to be created and initialised before loading the libraries. It would be better if this set up data was passed through a more obvious way, like through an initialize function with 20 parameters. As advise based on my own experience (note it's just friendly advise), you should only use global variables if there is no alternative or if the alternative is too complex/difficult/timely to use.
Sat, 25 Jul 2009, 12:35
Teasy	Just sharing alternatives