Dead
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.
Thanks man, Ill rework the thread
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.
Just a thought. Have fun. 
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
“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 exist
If 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?
Thanks again for those finds, +1
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.
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.
~Update~
Small Stuff
-improved physics, much less buggy
-added in some misc geometric methods
~Tools.getDistance(x1, y1, x2, y2)
~Tools.isCloseTo(a, b, tolerance)
-added dontCollideWith(Object obj) to the PhysicsObject
-added checkNormalColliders() to PhysicsObject, returns true if it’s hitting anything
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
I went to take a look at your Camera.java file and cringed at the monstrosities I saw.
First of all, you’ve limited the engine to a screen size of 1400x880. At least, that’s what I deduced from this:
public double getLocationX() {
if (objectSnappedTo == null) {
return locationX;
} else {
return objectSnappedTo.getObjectLocationX() - (1400/2);
}
}
public double getLocationY() {
if (objectSnappedTo == null) {
return locationY;
} else {
return objectSnappedTo.getObjectLocationY() + (880/2);
}
}
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)?
I like the new logo
Thanks man, Kpars did it for me 8)
I’m excited for this, seems like it can be a really great engine!
Thanks!
Ive been working really hard the last couple weeks on a huge update, it should be out soon.
I has to rewrite almost the entire physics engine for it!
I miss this project. I just remember saucymeatman sending me a little 3 second physics demo of a box dropping. That is literally the last I heard of it!