Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 28 Jul 2005
Offline Last Active Jul 14 2016 07:50 PM

#5059803 I'm desperate. Isometric Mouse Coordinates

Posted by on 06 May 2013 - 01:32 PM

I battled this a LONG LONG time ago back in '08 (took some searching, but here's the thread)
The resolution is below, quoted for proper credit biggrin.png.

its simple really, I'll start from tile--> screen and then see how it goes from screen to tile. Of course you should replace the numbers 64 and 32 by constants for easy change.

tile --> screen
for every tile you go in the X direction you go 64 pixels right and 32 pixels down,
for every tile you go in the Y direction you go 64 pixels left and 32 pixels down,

on screen right=positive x, left=negative x, up=negative y, down = positive y

so we get:
pixel_x = X_LOCATION_OF_TOP_MIDDLE_TILE + 64*tile_x - 64*tile_y
pixel_y = Y_LOCATION_OF_TOP_MIDDLE_TILE + 32*tile_x + 32*tile_y

now to do the screen --> tile
for ease of writing, pixel_x = px, tile_x = tx, X_LOCA... = X0

equation1: px = X0 + 64*(tx-ty)
equation2: py = Y0 + 32*(tx+ty)
we want to find equations for tx and ty when given px and py, so we do some algebra:

eq1+2*eq2 = px+2py = X0+2Y0 + 128*tx
---> tx = (px+2*py -X0-2Y0)/128

eq1-2eq2 = px-2py = X0-2*Y0 -128ty
---> ty = (px-2py - X0+2*Y0) /(-128)

I hope that was clear, and maybe you learned some math from it smile.png

the matrices are just compressed way to do the algebra.

[Edited by - Iftah on December 5, 2008 6:08:28 AM]

In order to get it to work, I had to change the 128's to 64's. It's been forever so I don't remember much of that code, but it should be pretty straight forward.
Hope it helps.

#5052146 Simple MORPG project planning

Posted by on 11 April 2013 - 09:47 AM

Yes, you definitely want to work closely with your client/network programmer(s) on that. If the clients input/physics/animation is not coded with the networking in mind, you're going to have bad times down the road. Building the client and the server each in a vacuum and then "Connecting" them after they're done is... Well, that's probably not the safest approach, we'll say.


Having a log in server to supply an auth ticket is not a problem, but be mindful of how many distinct "Servers" you have. For something small, as you are proposing you probably shouldn't need more than one server application.


I don't see a problem with having the dialogs in the database, but you'll definitely want to keep that stuff cached on the client in some sort of data files so you don't need to stream it constantly.


Your client and server do not need to be written in the same programming language. What's important is that they speak the same "language" over the network. What I mean mostly is your packet structures and protocols (TCP, UDP, HTTP[Probably don't do that], etc...).


Without knowing what sort of data you're storing in your DB, we can make no judgments on it's structure or table counts. So long as it's intelligently designed, and your queries don't have performance issues, you're probably going to be fine. 

#5051872 xna keyboard issues

Posted by on 10 April 2013 - 11:39 AM

As Andy said above, IsKeyDown is what you actually want in that scenario.


If your bullets aren't moving, you're probably not updating their position every frame :)

#5051622 I want to make a 2D game engine! Where do I start?

Posted by on 09 April 2013 - 04:19 PM

Well, you have quite a few options available to you. 


On the C# side you have XNA/MonoGame which is a pretty great framework that's very easy to get cooking with. You also have Playstation Mobile for Vita/PS Certified Android if you want to go that route.


There's also a ton of C++ options. I found SFML and Allegro 5 to be pretty easy to use, and if you can get the project setup right Cocos2d-X is pretty great as well, although a lot of the tooling is available only on Macs. You could also rough it and go straight to OpenGL/Direct X, but that's probably not the best plan for a 2D project. Of course, SDL is an option, I just personally prefer the more object oriented solutions.


Over in Java land, you also have quite a few options. LibGDX is the only one I'm at all familiar with, but it seems to be pretty feature rich and was rather easy to get going. It's also compatible with Android which I find to be a nice positive.


The number of available programming languages and SDK's is pretty much too great to count so it all comes down to what you want to do and what platform you want to do it on. Already know a language? Find an SDK/API that looks interesting and use it. Want to learn a new one? Go for it!

#5051275 Learnt C what next?

Posted by on 08 April 2013 - 01:42 PM

If you're wanting to target Mac/iOS exclusively, then yeah Objective-C is probably the way you'll want to go.

#5047314 Flash

Posted by on 27 March 2013 - 12:13 PM

I would say that your time would be better spent learning C# with Unity as it will probably turn out to be more useful for you later.


This isn't so much true if he wants to stick to 2D games. You CAN do 2D with Unity, but it isn't really the best tool for the job.

#5046651 Game character and scene managing

Posted by on 25 March 2013 - 03:03 PM

 Generally, You should pre-load anything that takes a measurable amount of time to, well, load, before you need to use it.



In your case, anything you're going to potentially need in the scene should be loaded up front during your existing loading period.



A more efficient method might be to start pre-loading additional assets on a background thread. You'd need to be able to accurately predict when a resource will be needed so that it can be loaded appropriately (alternatively, you just start pre-loading ALL the optional resources after the primary ones are loaded). Be wary of this approach though as attempting to access your objects before/while they're loading is in most cases going to end poorly.


Really though, just loading everything you might need for your scene is probably going to be good enough.

#5044218 Scope MADNESS

Posted by on 18 March 2013 - 08:07 AM

I've been doing C++ on and off for several years but I'd never heard of the Rule of Three so I looked it up and figured I'd drop the link here for reference. Thanks SiCrane.


@OP: What BCullis said. 


Haha I'd started to write more or less exactly that, but you beat me to it.

#5036808 What to write with now?

Posted by on 26 February 2013 - 01:13 PM

 Firstly, yeah, you still can. I haven't seen anything, nor does the creators club site in any way indicate that XBLIG submissions are no longer being accepted. If you have a link showing something to the contrary, I'd love to see it.


Now, if you're in an unsupported region, don't have the cash for a membership, or are simply wary of the profitability of the XBLIG portal, well, those are all valid concerns.


Don't let them stop you from using XNA though. There's are tons of other selling opportunities both on Windows or on other platforms (via MonoGame or Xamarinfor iOS and/or Android). Sites like The Humble Store, Desura, Gamers Gate... You can sell it for yourself.


But before you think about all that stuff, start making your game :)

#5036793 What to write with now?

Posted by on 26 February 2013 - 12:30 PM

This seems to come up a lot lately, and the sentiment is false. You can still download it right here.


Just because they are done updating it does not mean you can't use it. XNA is still a great framework for making Windows games and you CAN still write games for the Xbox.


Further, MonoGame exists and is more or less a cross platform port of XNA.

#5034264 trying to get camera working

Posted by on 19 February 2013 - 02:31 PM

Firstly, yes you can only have one spritebatch running at a time and that's usually fine.


I'm assuming your camera is or contains a matrix which you intend to pass into .Begin. Now, ideally, your camera object should be accessible from the highest level it's needed  - in this case, the spritebatch.Begin call that would be effected by the camera (so not for any UI components). Without seeing the code it's more complicated to guess at what you're doing but I'll try and provide a few options for you.

A. remove the begin call from the main class and have the begin called in the scene. This makes sense if the scene manages drawing all the objects for the scene. Alternatively, End the spritebatch call in the main class before the draw is called on the scene if main drawing something that won't be overwritten by the scene, or begin it afterwards if it is drawing some UI components that would be overwritten. 

B. put your camera instance in the main class and pass it around by parameter or property to the child objects that need it. This method is less clean, but it is a viable solution.


If neither of those work out feel free to include your problematic code in a post or via pastebin and we can try an help :)

#5034258 trying to understand gamestate,enum and main menu

Posted by on 19 February 2013 - 02:16 PM

While I agree that a switch statement is not an ideal way to handle game states, if your project is simple enough (read: You only have a few states) and you don't already have a more robust system handy, then a switch/case will work fine. Spending time building (or getting acquainted with a pre-built) GameState Management system is certainly a good investment in the long run, but for a simple learning project where you're trying to get used to the language and high level game dev concepts it can get in the way of the more interesting things like making things move around on the screen. smile.png

#5033842 trying to understand gamestate,enum and main menu

Posted by on 18 February 2013 - 12:24 PM

Not sure if I'm understanding your question exactly, but I'll try and answer what I think you're asking.


To start, you enum looks fine, and the switches in Update and Draw are how you'd utilise them. In order to get the most out of the structure though what you'll want to do is flesh out your ActionScene object.


It's Draw method should handle drawing all the things to be drawn while in the playing state such that

case GameState.Playing: 
     spriteBatch.Draw(actionBackTexture, new Rectangle(0, 0, screenWidth, screenHeight), Color.White); 

//becomes something like this
case GameState.Playing: 


You'll also want to do more or less the same thing with Update. Right now you have actionScene.LoadContent in the Playing state. This is bad because it's going to call LoadContent every frame, when all it should be doing is calling actionScene.Update(gameTime); With that said, you'll probably want to add an update method to that object to handle any updates that need to happen.


Your load content call could be moved to line 185 to ensure it only happens when needed, although you'll probably want to clean that up once it starts becoming more of a game.

#5019989 Help with movement in javascript [noob]

Posted by on 10 January 2013 - 02:19 PM

Happy to help!

#5019915 Sprite fails to draw when calling my draw() method

Posted by on 10 January 2013 - 11:21 AM

Drop a break point on the draw method and inspect the parameters (Seems like they should be fine, but wouldn't hurt to look).

Also, capture the return from the draw call. From MSDN: "If the method succeeds, the return value is S_OK. If the method fails, the return value can be one of the following: D3DERR_INVALIDCALL, D3DXERR_INVALIDDATA."

Unfortunately I'm not familiar enough with DX to be of much more assistance then that.