PureBasic Forums - English

I wanted to play around with some isometric code so I took code from dapsycho at http://www.blitzcoder.com/cgi-bin/showc ... omments=no and converted it to PB. Works pretty well. Figured I'd share it so anyone else interested can play too. The mousemap stuff is pretty neat to see in motion.

The code can be run windowed or full screen by adjusting the code that I have commented out at the start. Debug info can be turned on by removing the comments that keep it all hidden. All in all, pretty basic code but still cool.

http://www.slightlystunned.com/isometric.zip

The code is free for all uses, no catches.

Neat

Thanks.

Nice . Just one thing though, for me the the 'square' selection isnt always right. Sometimes a 'square' one or two away from the one the mouse is pointing at is selected.

Ah ha! Greengiant, thanks. I thought that I was going crazy.

If you turn on the debug routines that show the mousemap, you'll see that the mousemap has a small line of lime green pixels on it sometimes when you compile and run the program. Those pixels mess up the program and throw the selection thing off.

Here is the thing though.... it doesn't happen EVERY TIME! Arg. I've seen those pixel show up on the tall tile also. It doesn't happen on the blitz basic version and it doesn't happen on the small tile version either. I was thinking about posting a bug report about something going wacky with the loadsprite command, but I'm still not sure how to recreate the problem everytime.

I was hoping that someone would notice it if I posted the demo code and comment on it.

Anyhow, I'm still trying to figure out where that comes from. Maybe its because I'm not using square sprites?

update: Well, after poking around, it looks like it probably isn't the loadsprite command that is causing the trouble... it's the createsprite command.

I tried changing the order that I loaded the sprite in and the green bar jumped around to different sprites. I changed the talltile sprite to a 64x128 sprite just to make sure that it was ok... still had the trouble. Actually had it happen a couple times where the green bar would move to a different sprite when I would recompile the code.... with no changes made to the code!!!

Anyhow, when I moved the createsprite command to before the loadsprite commands, the green bar on my sprites seems to have gone away. Maybe createsprite isn't happy with #PB_Any or something... I didn't dig any further into it. Its the first time I've used createsprite so I don't know all the trick of the trade with it yet.

Originally in the program I was using images for the mousemap and the minimap in the corner but had a b*tch of a time with the images. I was trying to use the startdrawing(imageoutput()) command and was choosing the image with the UseImage command.... but it wouldn't choose the images that I wanted to use. The image ID that I was putting into the UseImage command was popping back out of it (Result = UseImage(#Image), where result!=#Image!!!!) Rather than bang my head I moved to sprites.

So anyhow, I don't know if doing the createsprite command always before the loadsprite commands is a 100% solution until Fred tracks the bug or not, but it seems to do the trick for now.

Really nice. And very fast. But i wonder if it is so fast too if there were more different objekts with a different shape. And not static objects, moving objects. Then the handling with that engine will be more difficult because now it is only for static objects, as i have seen until now. You're checking every single tile for a 0 or a 1, if 1 then placing an object there. But with objects, jumping from one to another tile, there yould be some troubles with that.
So up to this time, that is an engine for a game like Sim City 1 where no moving objects are. Only buildings.
But nevertheless a pretty nice engine, and all that with so little code.

Hello,

Can anyone give me this zip ?
The link is defect,too.

Hroudtwolf wrote:Hello,

Can anyone give me this zip ?
The link is defect,too.

Go to http://www.blitzcoder.com/cgi-bin/showc ... omments=no
There is a direct link to it

Oh. Thank you.
I didn't see it.

I'm trying to make an isometric engine...

aaron wrote:Ah ha! Greengiant, thanks. I thought that I was going crazy.

If you turn on the debug routines that show the mousemap, you'll see that the mousemap has a small line of lime green pixels on it sometimes when you compile and run the program. Those pixels mess up the program and throw the selection thing off.

Here is the thing though.... it doesn't happen EVERY TIME! Arg. I've seen those pixel show up on the tall tile also. It doesn't happen on the blitz basic version and it doesn't happen on the small tile version either. I was thinking about posting a bug report about something going wacky with the loadsprite command, but I'm still not sure how to recreate the problem everytime.

I was hoping that someone would notice it if I posted the demo code and comment on it.

Anyhow, I'm still trying to figure out where that comes from. Maybe its because I'm not using square sprites?

Well, I revisited this code after over a year and it wouldn't run with the latest version of PB.... the new debugger is much better at finding my stupid mistakes.

I should have clued in that the green stripe of colour that was showing up on some of my sprites just happened to be the same colour that is used on the map. In the function that I was using to draw into a sprite buffer for the minimap, I was writing outside the confines of my sprite by 1 pixel. The old debugger let me do it, and I guess that depending on how the compiler was assigning memory spaces for the sprites, I would overwrite other sprites. Anyhow, I updated that zip archive just so someone else doesn't wonder what an idiot I am when they go to compile the code.

I'm playing around with an Advance War type game but using isometric just for the hell of it.

Nice

Very nice

The scrolling with the cursor keys does not work, and there is no need for a Close-Window-Button, as the mouse cannot leave the area...

Doh! Guess which keys I never used after converting it from Blitz? I forgot the # in front of the PB constants for the keys. Doh! And then after testing it, realized that the keys were wrong anyhow... up/down and left/right were swapped.

Ah well, I'm an idiot. I re-uploaded the fixed code as well as added in a couple of other fixes... there was one more place where it was possible to plot outside the drawing areas and the map key was annoying so I added a check to make sure the user has released the map key before doing anything with the map again (gets rid of the annoying flashing map when holding the m key).

That's a good point about the minimize/close buttons. I had been intending on making the thing both full screen and windowed... while in windowed mode you would be able to move the mouse out of the screen obviously, or it would be really really annoying. There is a problem though.... scrolling with the mouse means that it can't really leave the window without scrolling becoming a pain in the butt.

Because Advance Wars is a turn based game, I was thinking of it as more of a casual type game where it would be handy to have in a window rather than full screen (ie- hide it behind another window when the boss shows up). A full screen option is always nice though, in addition. I don't like the idea of being only full screen. I dunno... needs some thought I guess.

Any suggestions?