So?
Make it hard to read then! I’ll take speed over convenience any day.
Why? If you separate the concerns, it won’t happen except if your engine isn’t very flexible.
Oops, enjoy the medal…
Anyway, I doubt this is entirely true. Since you mention it, it’s probably true with how your code is currently, but after some design considerations and a rewrite I’m sure you can do better.
Optimized software rendering is ugly and dirty no matter how you structure things. It’s as low level as it gets with Java and it involves a lot of bit fiddling and fixed point stuff. So he has a point: If you optimize it, the code will get ugly. There’s no way around that. Personally, I would do it anyway. jPCT’s software renderer runs circles around this one (even on one core, let alone when using multi-threading), but its inner loop IS ugly and hard to understand.
Ya know when I first looked at this thread I thought “hmm is this software?” and then today I guess it slipped my mind. Please feel free to ignore my comment.
Thank you for explaining 
Should I remove the specular highlight support in the engine? It will greatly help with speed and memory
EDIT: im leaning towards removing it and getting a new stone texture that looks good without specular
It’s hardly noticable anyway, so not much harm would be done by removing it IMHO. Or consider to create different inner loops, one for each variation. But that’s the same ugly vs. fast discussion that we had before.
BTW: Per polygon mip-mapping might help to reduce the aliasing in the distance and isn’t very hard to do.
Doesn’t mip mapping use more memory?
EDIT: Well I just implemented it and sure there are less artifacts but is more memory worth it?
Of course it uses more memory, but it’s worth it. What’s the point in not using the memory that modern systems have?
How much memory, do you think, is too much memory usage in a java game like mine?
I don’t think that there’s a definitive answer to this question. First, I don’t think that there are different standards for Java- and non-Java-games. The memory doesn’t care who consumes it. Personally, I would say that everything that can run within a JVM that has been started with -Xmx512m is fine on today’s machines.
Ah okay thanks I haven’t needed to use JVM arguments for this game yet so it looks like my game is totally okay memory wise 
EDIT: do you have a skype? having conversations in a thread is kind of annoying in my opinion and I will probably have more questions for you since you are an expert at software rasterization
http://www.mediafire.com/download/6haa41456ca39e1/ShardMasterClassic_inputdemo.jar
Try the input demo. Tell me which you prefer, I am curious :p.
Modes:
0 = drag
1 = mouse wheel
2 = Q, E for camera
3 = A, D for camera
you use the number keys to change mode
VK_1 is mode 0, etc…
I prefer mode 0 followed by mode 2. Mode 3 is tolerable as well, but mode 1 isn’t!
Thank you for the input EgonOlsen
From best to worst, 0 3 2 1.
Also, I feel as though this wasn’t supposed to be possible, but I went full jesus.
Yeah it’s a bug that i’ve already looked into. it happens when you are running into a non-traversable tile continuously and rotate the camera so it faces away from the collision, you end up being pushed back into the non-traversable tile haha.
I’m surprised people like the click-drag camera controls. It just doesnt seem like it’ll work because interaction with the world is done by clicking on objects in the 3d world and if clicking and moving your mouse a little makes the camera move, it would be very weird.
Best to worst: 0, 3, 2, 1. A little bug I found was after switching modes some modes would blend into each other (only case I had was drag mode and AD mode stuck together. Mode 2 didn’t use my QE keys, but rather the R and F keys (I use a QWERTY keyboard). Drag controls are okay, I would suggest putting it on right or middle click, but not left click since that’s your interaction button. Also, input sometimes doesn’t register (I think it’s because you’re polling and not using events).
I also got stuck in an evergreen tree (same way NegativeZero got stuck in water), but I saw that you’re looking into it.
I actually rather like the idea of mode 3 and 0 together. AD would rotate the character and move the camera, but drag would move the camera and offset it. This way you could have the camera looking in a different direction relative to the player.
Nice job so far!
Yup I also stumbled across that blending bug haha, it was just for the demo and i just fixed it 5 mins ago :p.
Oh yeah and about the QE switching with RF thing happening, it was my fault because I updated the jar that you download with that link and the old one had QE but the updated version changed it to RF.
I like that idea! Combining mode 3 and 0 would be pretty nice but i think that moving sideways might be something that is necessary in the game and since mode 3 removes that, I think it could be problematic.
I added options to the settings tab that let you switch between Dragging/QE/RF/ and CV