The source code is a bit messy but I have succeeded in detecting collisions between the projectiles and the enemies.
I assume you can read. I rarely post here several times per day, I post some updates. I don’t see any multiposts.
I don’t see the point, maybe I should sleep much.
That’s my fault. It is very slow without my optimizations, I have not yet ported them to Ardor3D.
You have to pick the right ammunition and the right weapon. Of course you cannot use cartridges with the pistol. Use the scroll or some keys to select a weapon, they are indicated in the menu.
Feel free to use them, they are under “free” licence(s). My skills with Blender are lower than yours :-X
Something is still wrong with the collisions between the player and the walls.
You’re right.
I might move it into a separate level as it was just a test.
I might move it too and I don’t use it correctly.
Thanks but there are still a lot of things to improve, it is even not as playable as the “old” alpha version.
Yes it is really annoying. I implemented collisions with the walls very quickly, I will have to rewrite them, it is crappy and not accurate enough.
I have not yet updated the demo of the pre-beta version. I will do so when the source code is more beautiful.
Thank you for the feedbacks and sorry for the late reply. I didn’t notice your posts. There are obviously tons of wrong things in my game and it is still under development, I will take into account your comments.
Ok but it would be really problematic if nobody read these posts… which is not the case ;D
I have only updated the source code, feel free to kill people as it is now working. I’m so happy, it is far from perfect but it is better than nothing.
I have just updated the demo. Don’t forget to look at the key bindings in the menu before playing if you don’t know how to select weapons, reload, etc…
I won’t do that because a fat JAR is less reliable than Java Web Start (I already explained it several times in other threads), a zip archive is not satisfying because my script would not work in some particular cases (Java installed but not in the path, 32 bits vm on a 64 bits machine, etc…). I prefer helping you to fix your problem.
OpenJDK works fine for me:
[quote]java version “1.6.0_22”
OpenJDK Runtime Environment (IcedTea6 1.10.8) (fedora-28.b22.1.mga1-i386)
OpenJDK Client VM (build 20.0-b11, mixed mode)
[/quote]
I use OpenJDK and Icedtea for several years now. I can try to solve your problem. Please let me know which distro you use, which version of OpenJDK and which version of Icedtea. What do you mean by “JNLP’s don’t work for me”? If you don’t succeed in using them from your web browser, try to do it in command line:
[quote]javaws http://tuer.sourceforge.net/very_experimental/tuer.jnlp
[/quote]
I will write a bug report if something is really broken in OpenJDK. I blame nobody and nothing, I just want Java Web Start and NetX to work fine. Best regards.
Edit.: Check if you have already installed icedtea-web package. If so, enable logging and tracing in Icedtea Web Control Panel and let me know which error message(s) you get in the log.
The javaws command works perfectly.
Maybe It’s Chromiums fault. Haven’t tried it on Firefox yet…
So I have played your game now. Couldn’t play it tough… I still have problems with XRandr and fullscreen applications. If LWJGL’s XRandr stuff is disabled, all the DisplayModes other than the 2-monitor wide display mode fail, and cause the application to stop immediatly.
That alone is not too bad: I SHOULD still be able to play it in 2 screens, but the game is only showing on one screen. I really don’t know why… Unplayable right now
BTW:
Archlinux, latest.
And:
[quote]$ java -version
java version “1.6.0_24”
OpenJDK Runtime Environment (IcedTea6 1.11.2) (ArchLinux-6.b24_1.11.2-1-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
[/quote]
And thanks for your support
You really should take the like 5 mins to write a launcher for the 3 big OSes and make this a desktop app. No one wants to wait 10 mins to download a web-game. Also, JWS and applets suck, but that’s out of scope of this topic.
How goes development? You really should display a screenshot or video of what you got so far. :3
I don’t use LWJGL but NEWT (JOGL) uses XRandr too, like LWJGL native windowing system. If I don’t use NEWT, I cannot use the full screen mode under GNU Linux because of an AWT bug (the task bar is drawn above the window).
Why is it unplayable right now? It is intentional, I ask NEWT to use only the primary screen by default to work around some (native) bugs with the support of multiple monitors when its order has been changed.
And thanks for your support
[/quote]
You’re welcome.
That’s Google’s fault, I provided them a patch to fix that, one of its employees prefered suggesting a weaker patch. When you come here, you can see that I show a nice message to explain the situation:
[quote]Google Chrome is not supported. Launch the game with your file browser or install it with another web browser.
You can find more information about this bug of Google Chrome here.
[/quote]
Google is still trying to kill Java, it still shows a scary warning when I try to run my game with Chrome:
[quote]Ce type de fichier risque d’endommager votre ordinateur. Voulez-vous vraiment enregistrer tuer.jnlp?
[/quote]
[quote]This type of file may harm your computer. Do you really want to save tuer.jnlp?
[/quote]
Then you have to click on the arrow on the right and choose “Open”. After that, the game works fine.
There is no automatic update in native installers and IzPack. It means that if I use one of them, when a player runs my game, an obsolete version will be used instead of the latest one whereas my game is far from finished. Your suggestion would be interesting for a polished and stable game, TUER is neither polished nor fully stable. TUER is seen as a “web” game but it is rather a desktop application that can be launched from the web. Java Web Start does not suck, I can work around some of its broken features and actually, Google sucks. Anyway, your suggestion would not reduce the time spent to download the game, the very first versions of TUER (available as zip archives) took ages to download. TUER will use more and more sound samples (ogg) and models, it will take much time to run. I don’t intend to make a very casual game with a very few artworks and tiny levels, therefore people will have to spend some time in installing it or give up and rather play with “smaller” games.
I will put some screenshots into my next article and I will ask Sven to help me to make a video as my machines are too slow.
TUER attempts to use only the primary screen. If your operating system shows your both screens as a single wide screen, it will use it as is. I will try to fix that, maybe I misuse NEWT but I’m not sure I will succeed.
I see what you meant, don’t worry. I use the wrong instance of com.jogamp.newt.Screen (the default one) when creating an instance of com.jogamp.newt.opengl.GLWindow. If NEWT (through XRandR) doesn’t report only 2-monitor screens, I will be able to find a way to get 1-monitor screens, otherwise I won’t be able to fix this bug.
well you know, windows here
when I get the screens via lwjgl or anything else, it shows 3 screen with their own resolution; or 2 depending on where I test =D
so imo there shouldnt be any reason why any program would think its one big screen
I use the default “screen”, the screen that you use before launching my game, the 2-monitor wide screen. That’s why you have this problem. I have only one screen and no Microsoft Windows operating system, I will fix that but not as fast as I would like to do it. If choosing the single primary screen was absolutely trivial, I would already have done it. Blindly fixing bugs without being able to reproduce them is not easy.
