There has got to be a way to do this
Displaying 1-10 of 10 total.
1
Technetium

I have been having some struggles with getting rendermap to do exactly what I want it to do. The end result of what I am aiming for is to have a image in memory that contains the map from (xwin-160,ywin-200) to (xwin+800,ywin+280). I want to only have to render the tiles actually within that area, because the map is 1000x1000 tiles and rendering the whole thing is way too slow.

Right now I have the function create the image (960x480), and then I tell it to rendermap(0-(xwin+160), 0-(ywin+200), imagebuff) but this causes it to freeze for several seconds before exiting with no explanation. My guess would be that it runs out of memory trying to render one million tiles over 5 layers, but again, I don't want it to render the entire map, just a specific area.

This seems like a pretty basic thing I am trying to do, but I'm not sure how to get it to work. Any suggestions?

Posted on 2005-05-24 11:41:03

Want to reply? login or register!

mcgrue

AFAIK, rendermap does in fact render the whole map...

You may be able to use GetTile with BlitTile over all your layers and make a buffer of your current screen in an image faster that way...

Posted on 2005-05-24 12:17:24

Want to reply? login or register!

Technetium

That is what I am working on right now, actually. Actually, the whole point of this is that I am trying to write a fake 3D system for the world map that runs like the one in FF6. It works, sort of, but the biggest problem is that when the character walks, the skewed tiles will jump suddenly from one to the next, because gettile doesn't care if you are 'almost' to the next tile. I have solved some of that problem by having it locate how far from the exact tile coordinate the character is ('entity.x - ((entity.x/16)*16)' works pretty well to calculate this offset, but I can't get it to work at all on the y-axis for some reason).

Posted on 2005-05-24 14:20:58

Want to reply? login or register!

Omni

Try using a loop to render one screen of your map at a time into a buffer image destination (which is the size of the current screen, say 320x240).

Then, take this buffer and add each new screen to the larger 900xwhatever supa-buffer.

Maybe a little hackish, but surely it would work piece by piece.

I don't quite understand why RenderMap is so slow here. It should be leagues faster than any custom tile by tile blitter.

Posted on 2005-05-24 15:19:20

Want to reply? login or register!

Kildorf

I suspect that what renderMap() does is make a temporary copy of the entire map, then blit whatever portion of that will fit in your image into the actual image. Look at it this way:

1,000 x 1,000 tiles = 1,000,000 tiles
Each tile is: 16 x 16 pixels = 256 pixels, each at 32-bit colour depth, which is 1024 bytes; 1kb

So you're looking at 1,000,000 kb... that's a gig of memory for the map copy. Unless you've got that kind of memory lying around, you're going to have problems.

I have managed to renderMap() 300x300 maps, but I have a gig of RAM, and there wasn't enough memory left over to copy that image to the clipboard. That's significantly smaller than what you're trying to do. I'm thinking a custom VC tileblit solution will probably be the best way to go.

Posted on 2005-05-24 19:40:44

Want to reply? login or register!

Omni

Use normal Render() on the screen. Each render, copy the screen to your larger clipboard. Surely Render()-ing screen by screen doesn't use a Gig of memory.

I certainly hope RenderMap() doesn't work like that. I mean, I guess it's logical, but in a situation like this it seems _very_ inefficient...

Posted on 2005-05-25 14:57:02

Want to reply? login or register!

Technetium

Quote:Originally posted by Omni

Use normal Render() on the screen. Each render, copy the screen to your larger clipboard. Surely Render()-ing screen by screen doesn't use a Gig of memory.

I certainly hope RenderMap() doesn't work like that. I mean, I guess it's logical, but in a situation like this it seems _very_ inefficient...


The problem with that idea is that I need to get parts of the map which are off-screen.

Here is the main problem: I want to completely redraw an area of the map using TBlitTile. I have to use TBlitTile because it has tiles off-screen, but let's just say I need to get the tiles on-screen to make it easier to explain. I can get past the part where I draw the tiles to a 640x480 image using this method. But I want it to scroll smoothly, not jumping entire tiles at a time, so I need to blit this image slightly off based on how far the entity is from the 0-point of the tile coordinate. This is the code I am using right now:


blit(0-(entity.x[mainchar]-((entity.x[mainchar]/16)*16)),0-(entity.y[mainchar]-((entity.y[mainchar]/16)*16)),imagestuff,screen);

The part that I added to the x position does it's job very well, scrolling the map smoothly when the character moves from left to right. But the part I added to y position does not work right. The screen, when moving down or up, will generally scroll in the correct direction, but it will move in a bouncy manner. It doesn't make any sense to me why the math for handling vertical character position would be different for the math handling horizontal position.

Oh, and I also think RenderMap would be far more useful if it was rendermap(sx1,sy1,sx2,sy2,dx,dy,srcimg,destimg).

EDIT: Based on a lot of testing, I have concluded that Verge calculates tile position on the y-axis differently than it does on the x-axis. Tile position changes on the y-axis when you have traveled halfway down/up the tile. It changes on the x-axis when you have traveled all 16 pixels across the tile. I would love it if someone who knows could verify or deny this.

EDIT: Woo-hoo, solved the problem. There was a number lost in the code that I had chosen arbitrarily, but it turned out it needed to be divisible by 16 or the whole thing was off. I may post a demo of this thing when I get it finished. Thanks.

Posted on 2005-05-25 18:24:25 (last edited on 2005-05-25 19:39:13)

Want to reply? login or register!

Omni

As a side note, my intention was, that if you were to use Render() looped to draw the map to the larger buffer, you would also increment through xwin and ywin to run through the entire map. Then return xwin and ywin to normal once you were finished.

Posted on 2005-05-26 09:15:38

Want to reply? login or register!

rpgking

I made a system like this in Verge2 by Rendering the map into a buffer large enough to hold the current screen, splitting it into horizontal scanlines, and then rendering appropriately. The final product ran pretty fast and did look like the mode7 effect seen in some SNES games like FF6(minus the rotation).

Haven't gotten around to porting this to Verge3...

Posted on 2005-05-26 09:41:48 (last edited on 2005-05-26 09:49:00)

Want to reply? login or register!

Technetium

rpgking, I am glad to know who did that demo, because it was remembering the basics of how that system worked that led me to figuring out this one. There is a screenshot of it, btw, in the artists forum.

Posted on 2005-05-26 22:22:23 (last edited on 2005-05-26 22:22:55)

Want to reply? login or register!


Displaying 1-10 of 10 total.
1
 
Newest messages

Ben McGraw's lovingly crafted this website from scratch for years.
It's a lot prettier this go around because of Jon Wofford.
Verge-rpg.com is a member of the lunarnet irc network, and would like to take this opportunity to remind you that regardless how babies taste, it is wrong to eat them.