Upload your image to an image hosting site like imgur and use the [img]url to picture[/img ] tags.As for the engine, sorry but I don't think anyone will look at it if you don't provide clear and friendly examples of your code and what it can do. Just linking us to your source code isn't enough, I want to know what I can do with it. Pictures, videos and code are necessary, almost, to attract attention to your project. Not just a large page of text.

I like this. Seems like you actually have a little more going on then the other "Game Engines" people post on here.

One thing I strongly suggest if you do not mind, try using libs that are out there for certain tasks. Unless you want to reinvent the wheel, which is fine, there are libs out there that have been put through the gauntlet and work well instead of some code you write which may be wonky. Part of a game engine is to link all the different components people may use in a very thought out manner. Its not just about physics, pathfinding, AI, rendering but how they interact and how easy/hard it is to do certain things. Good GUI stuff can be a huge pain and your time may be spent somewhere else in the engine that needs it so why not integrate a lib that is already out there.

Some issues found:* Camera creates a thread on each smoothMove(). First, rather use thread pools for creating many threads, second, it is not thread safe and a generally questionable idea* Object inherits from image class, but a game object is no image but may use one. Makes usage of Object unnecessarily inflexible* Drop RelativeImage completely, has no right to exist* Object adds itself to some external collection in an unfinished state* Object.smoothMove() should not put the current thread to sleep - it does not know how threads are handled at that point* PhysicsObject uses threads but is not threadsafe* PhysicsObject should not implicitly start working from its constructor* Members of Level should not be static

Lethal Running - a RPG about a deadly game show held in a futuristic dysoptian society.

"I like this. Seems like you actually have a little more going on then the other "Game Engines" people post on here."

Thanks! Im glad you like it, replies like that keep me coding. (+1)

"One thing I strongly suggest if you do not mind, try using libs that are out there for certain tasks."

Yea thats a good idea. Particularly for rendering, LWJGL is GPU accelerated. But for now at least, the engine will be indipendent of other game librarys or engines.

"* Camera creates a thread on each smoothMove(). First, rather use thread pools for creating many threads, second, it is not thread safe and a generally questionable idea"First off, thanks for looking through my code and finding things that I missed. Not many people would go that far to help someone they dont know. Secondly, now that Im looking through my code several things arnt thread safe, ill work on that right away.

"Object inherits from image class, but a game object is no image but may use one. Makes usage of Object unnecessarily inflexible"Yea your right.

Drop RelativeImage completely, has no right to existIf someone wants to have an image upon screen, without it being rendered relative to the camera, Image makes sense to use, where a relative image would be used in other ways. Why no right to exist?

Drop RelativeImage completely, has no right to existIf someone wants to have an image upon screen, without it being rendered relative to the camera, Image makes sense to use, where a relative image would be used in other ways. Why no right to exist?

Because it is inflexible.What does RelativeImage actually change ? Another way of calculating a location. That is done by injecting a hardcored static reference to another class. Not good. Always keep dependencies low between classes.Images do not need to know the context in which and how they are used - let class users decide what to do for each use case.

Lethal Running - a RPG about a deadly game show held in a futuristic dysoptian society.

I think I understand what you mean. I think the best solution would be to combine them and have a boolean in image like isStatic, which by default will be false. That would probably be the best way to fix this right?

An image is, well an image... a wrapper around some bytes. Maybe it can draw itself, to be generous.Actually it does not even have a location - that is part of a use case, like for example when it is used to represent a game object. Remove the location and you can draw the same image object to different places, otherwise you need to create new objects.Limiting class responsibilities simplifies class design, programming, testing, maintaining.

Lethal Running - a RPG about a deadly game show held in a futuristic dysoptian society.

Bigger Improvments-new video, in the original post-added rotate(double amount) to Object, Collider and Image, this is in preparation for rotationalMomentum and the huge planned improvments in the physics engine that will distribute collision force between xMomentum, yMomentum, and rotationalMomentum disproportionaly

If someone snapped the camera to an object, then tried to use getLocationX() or getLocationY() and the window size was not 1400x880, their entire game gets screwed up if they use those values.

There's sooo many things wrong with smoothMove. First of all, why are you creating TWO threads??? One would have been bad enough, but two? Just to move the camera? And what about accounting for different framerates? What if I wanted the camera to take 5 seconds moving to a location? What if I wanted 0.5 seconds?What you should do is change smoothMove to take a time variable, then set a boolean isSmoothMoving as true.Give the camera an update(float deltaTime) function and have it check if isSmoothMoving is true. Based on its current location and angle between that and it's desired moveLocation, you should be able to figure out what to do. It's much more difficult than what you have now, but infinitely better.

"return objectSnappedTo.getObjectLocationX() - (1400/2)"This was only temporary, it centers the camera around a object at the center of the default window size.

Ill fix smoothMove() now. It should defiantly have a speed or time parameter.I don't know about giving the camera a update timer, it doesn't really need one. What you describe can be done without one.Maybe,smoothMove(double desiredX, double desiredY, double time)?

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org