🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Two questions: files and levels
Author
I''m implementing the levels for my current game, and I had two questions, one about drawing the map and one about loading.
1) For the drawing functions, I assume the way to draw a tile based map is to calculate which tiles should be displayed on the screen, and then go through in a for loop and Blt each one to the screen (can''t use BltFast because that doesn''t do dest rectangles, right?) I was just wondering if, by any chance, there is a faster way? I know this will work, but it just seems sort of slow...
2) My level file contains all the levels for the game, and I would rather avoid having to seek to the correct level every time I load one (since the levels are all different sizes) so would it be safe to just keep the file handle open to the level for the whole time the game is running? Most of the time I am told to close files as soon as possible, but is there a problem with leaving it open? Or should I just save the file pointer and re-initialize it next time I open the file?
-----------------------------
"And I write and I write and I don't believe it's gonna change today"
- From Yellow Ledbetter by Pearl Jam
http://www.crosswinds.net/~uselessknowledge
For problem #2:
Have you thought about storing an index header at the beginning of your level file? That way, you could get away with closing the file after each use -- generally a better idea..
When you load a new level, you''d simply open the file, load the (fixed length) index info, and use that info to get to the right point inside the file.
Notwen
Have you thought about storing an index header at the beginning of your level file? That way, you could get away with closing the file after each use -- generally a better idea..
When you load a new level, you''d simply open the file, load the (fixed length) index info, and use that info to get to the right point inside the file.
Notwen
Alright, I''ll take a shot at answering your Qs...
1) That''s pretty much the algorithm I use (although you can use BltFast, the dest rect is the same size as the src rect by default, just supply it the upper left hand corners to blit it to) and it seems to work just fine and perfectly fast. Granted, I have a Diamond Viper v770 for a video card, but I don''t think that you''ll suffer many problems using this sort of method...As for a faster way, there are ways that take more memory, but I happen to like this one because it allows for special effects you can do on the fly...
2) Definitely don''t keep it open - I suggest opening it, reading in all the information you need at the given time, and then closing it...If the levels are sequential, you can keep track of your position in the file, otherwise you can have an algorithm that reads header information in the file stating the size of each level to "jump" to the right point to start loading the level in...
- Ah, to write code; to compose electrical music, to manipulate the bits that make up everything...such is our chosen line of work. And for a game, no less!
1) That''s pretty much the algorithm I use (although you can use BltFast, the dest rect is the same size as the src rect by default, just supply it the upper left hand corners to blit it to) and it seems to work just fine and perfectly fast. Granted, I have a Diamond Viper v770 for a video card, but I don''t think that you''ll suffer many problems using this sort of method...As for a faster way, there are ways that take more memory, but I happen to like this one because it allows for special effects you can do on the fly...
2) Definitely don''t keep it open - I suggest opening it, reading in all the information you need at the given time, and then closing it...If the levels are sequential, you can keep track of your position in the file, otherwise you can have an algorithm that reads header information in the file stating the size of each level to "jump" to the right point to start loading the level in...
- Ah, to write code; to compose electrical music, to manipulate the bits that make up everything...such is our chosen line of work. And for a game, no less!
Author
By keeping track of the position in the file, do you mean storing the file pointer before I close it? If I do this, will the file pointer be to the same place every time I open it, or will it change? I thought about reading the level header then skipping the size of the level, but if there's an easier way (like if storing the level pointer works) then I'd rather do that...
Oh, and by the way, I said I had to use Blt rather than BltFast because the game is smooth scrolling, so I am going to have to clip to the edge of the screen. Or does BltFast work with clippers? I might just write my own code, right now I'm working with my own bitmap code, and not using the Blt functions at all..
Edited by - Qoy on 1/12/00 12:31:03 AM
Oh, and by the way, I said I had to use Blt rather than BltFast because the game is smooth scrolling, so I am going to have to clip to the edge of the screen. Or does BltFast work with clippers? I might just write my own code, right now I'm working with my own bitmap code, and not using the Blt functions at all..
Edited by - Qoy on 1/12/00 12:31:03 AM
Best way to keep track of the position in the file is do an ftell at the point you want to save, and an fseek from SEEK_SET when you reopen the file. Or use the equivalent functions for whatever file reading code you are using.
As for using BltFast, you can infact write your own screen edge clipper for BltFast without using DDClippers. Simply reduce your source rectangle to however much of the sprite is visible. I''m not going to give an in depth explanation but if you can''t figure it out, reply to this post and I''ll post some sample code or something.
Regards
Starfall
As for using BltFast, you can infact write your own screen edge clipper for BltFast without using DDClippers. Simply reduce your source rectangle to however much of the sprite is visible. I''m not going to give an in depth explanation but if you can''t figure it out, reply to this post and I''ll post some sample code or something.
Regards
Starfall
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
