1 (edited by Elviz 2015-09-21 18:40:34)

Topic: Nuncabola

http://uppgarn.com/files/nuncabola/screenshot1-tn.png http://uppgarn.com/files/nuncabola/screenshot2-tn.png

Nuncabola

As avid readers of this forum may know, the lockstep graphics never worked for me. That's why I was disappointed to see Neverball 1.5 released with the "very apparent and quite disturbing" judder left unfixed. This, among other reasons, motivated me to finally start my own, personal version of Neverball. The result is a Java application I've called Nuncabola, and I'm sharing it here with anyone who is interested.

In order to enable productive work, I decided to redesign the entire code structure. Internally, this is a complete rewrite. Externally, Nuncabola is still rather faithful to Neverball in terms of design and features. However, a number of changes have already been made, and more may be introduced as development continues. For details, see the posts below.

Downloads and additional information are available from the Nuncabola website.

Comments and bug reports are welcome.

2 (edited by Elviz 2012-11-23 06:57:45)

Re: Nuncabola

http://uppgarn.com/files/nuncabola/screenshot3-tn.png http://uppgarn.com/files/nuncabola/screenshot4-tn.png

Changes between Neverball r2856 and Nuncabola 0.1:

General:

  • Nuncabola uses some simple interpolation between game states to fix the problem of stuttering graphics. As discussed in Glenn Fiedler's article, this is actually a crucial part of a fixed-timestep design. With this code in place, graphics are now again as smooth as those of 1.4.0 (1).

  • It's worth mentioning that there was (and is) a second problem source contributing to the judder in Neverball. On some systems with NVIDIA drivers, calls to SDL_PollEvent may take unreasonably long when the driver setting "threaded optimization" is set to "on" (its default value). The delay is on the order of the screen refresh interval, disrupting the timing of the main loop. I would advise anyone who is affected to turn off threaded optimization.

Directory structure:

  • With Nuncabola, there are separate directories for score files, replays and screenshots. The structure now looks like this:
    =
    Nuncabola
      |
      |_ Replays
      |   |_ easy-01_01.nbr
      |   |_ ...
      |
      |_ Scores
      |   |_ scores-easy.txt
      |   |_ scores-easy-cheat.txt
      |   |_ ...
      |
      |_ Screenshots
      |   |_ easy
      |   |   |_ bumper.png
      |   |   |_ ...
      |   |
      |   |_ screen00001.png
      |   |_ ...
      |
      |_ error_log.txt
      |_ preferences.txt
    =

  • As indicated above, there is a separate set of highscore files for cheat mode results; testing no longer affects your legitimate scores

  • When taking screen shots for an entire set, an appropriate subdirectory is automatically created in Screenshots. (I could never remember the setup needed for Neverball to save F12 set shots...)

  • The file error_log.txt records stack traces of errors of which there hopefully will be few.

Simulation:

  • The ball can now pick up any number of items during an update, not just one

  • First update now includes initial view information so it does not have to be regenerated at playback time (as st_demo.c does)

  • Limited amplitude of bounce sounds to 1.0f

Graphics:

  • Doubled the number of halo sides (1)

  • Fixed the "crazy reflection" problem by reinitializing the video configuration upon stencil changes (1)

Playing:

  • Returned the effective default rates for manual camera rotation to what they were in 1.4.0 (based on Chase rather than Manual) (1, 2, 3)

  • The current level and its textures are cached; restarting is near instantaneous even for large maps

  • Renamed "Normal mode" to "Standard mode"; noun instead of an adjective (1)

  • Rotating left using the Z-axis actually rotates the camera left instead of right (and vice versa)

  • Using (either Left or) Right Shift for fast rotation works again (as it did before the patch)

  • The middle mouse button now toggles the camera by default

  • Changed default key binding for camera toggling to "x"; "e" is too easy to press accidentally while reaching for the "r" restart key

  • In the play end screens, buttons such as "Next Level" or "Save Replay" are now disabled instead of removed when not applicable, giving the user a consistent place to click on for retrying a level; this is the way it was before the progress branch was merged

  • Renamed "Exit" to "Quit" in the fall-out/time-out screens; "Exit" should be reserved for exiting the application

  • No HUD while pausing during the Ready/Set stage

  • Made it possible to leave pose mode by hitting F12 a second time

  • Added ability to have an empty replay name pattern

  • Correct highscore time for levels with "unlimited" time (e.g., map-misc/bounce.sol)

Replays:

  • Replays recorded with UPS != 90 are played back at the right speed

  • Replay warning message: "map" -> "level"; level is more of an end-user term

  • Replay warning message: "you're" -> "you are"

  • One-second "Replay" intro can be clicked away; especially useful after clicking away the warning for an incompatible replay

  • When pausing a replay, the music pauses instead of continuing silently

Scoreboards:

  • Unified layout for all record categories: time left, coins right

  • Enabled cycling through record categories using the mouse wheel (1)

  • Categories containing a new record are now highlighted in green (1)

  • "Best Times" -> "Best Time"; using the plural is too awkward given the other categories: "Most Coinses"? "Fast Unlocks"?

  • For the price of some padding in the coin column, the scoreboard title and player names are now equally centered (looks much better)

Screens:

  • Time spent while switching screens is no longer counted against the destination screen; unless requested otherwise, each screen starts with a clean slate: for example, the fade animation will no longer be "swallowed" if a level takes a long time to load

  • Joystick recentering requirements no longer affect the arrow keys

  • Automatic and accurate truncation of long label texts, either at the end (like thi...) or at the beginning (...ike this); for an example, see the name field in the replay list screen

  • Title screen: Disabled sound effects for replays (1)

  • Title screen: Turning off cheat mode clears wireframe mode (if set)

  • Level set list screen: "No Level Sets" message if sets.txt does not contain any level sets

  • Level set list screen: Increased page size to 6 (for visual consistency with the corresponding six lines on the level set screen)

  • Level set list screen: Proper display of set descriptions with fewer than five lines; you no longer have to pad the text with trailing "" characters

  • Level set screen: "No Levels" message if there are no levels

  • Replay list screen: Improved loading time by reading replay headers on demand; the downside is that invalid files will appear as (unselectable) entries in the list. However, with the new dedicated replay directory this shouldn't be a problem

  • Options screen: Swapped resolution and fullscreen rows

  • Options screen: Fullscreen buttons are now disabled if fullscreen mode is not available for the chosen resolution

  • Resolution screen: Left (instead of right) alignment for buttons in incomplete rows

  • Resolution screen: Added menu sounds

  • Player name screen: Disabled OK button when name is empty

  • Replay name screen: Disabled OK button when name is empty

  • Layout and spacing tweaks in several screens

Application window and OS integration:

  • Support for window positioning (window_x, window_y preferences); note that these values have to be specified manually (default is -1 for automatic positioning) (1)

  • The initial window size of 800x600 (plus trimmings) is used only if the desktop resolution is bigger than 800x600 to prevent the window from opening partially off-screen

  • Thanks to LWJGL not interfering, Alt+F4 closes the window on Windows (1)

  • On-screen keyboard: Support for the Alt+Numpad input method on Windows

Preferences:

  • Removed d-pad preferences; in Nuncabola, the directional pad is handled along with the axes

  • Boolean values are saved as "true"/"false" to better distinguish them from integer values; specifying them as 1/0 remains possible

  • Mouse wheel bindings are saved as "Wheel Up"/"Wheel Down" for consistency with key naming (e.g., "Page Up"); specifying them as "wheelup"/"wheeldown" remains possible

Level sets:

  • Nevermania level shots are included as 24-bit PNGs (1)

Not implemented:

  • nice, stats and uniform options

  • -i command line argument

  • SOL name display in cheat mode (made the layout look bad - not worth it)

  • 'c' function in cheat mode

  • Use of key combinations for configurable keys (i.e., no Ctrl+F3, Alt+R, etc.)

  • Tilt sensor support

  • Internationalization

  • Installer

  • mapc port

  • ...and no Nuncaputt

Known issues:

  • Window/Taskbar icon does not have proper alpha (apparent limitation in LWJGL)

  • "menu.ogg" and "coin.ogg" had to be reencoded because the decoder would not read them

3 (edited by themacmeister 2010-07-23 03:12:14)

Re: Nuncabola

That is supremely EPIC work Elviz.

Check here for alpha-transparency icons under LWJGL -> http://www.jmonkeyengine.com/jmeforum/i … pic=3300.0

Good Luck, and GREAT WORK!

PS. Just got a new AMD Athlon X2 6000+ system + 4MB 800MHz DDR2 DRAM - HOO BOY!!!

EDIT: 4MB of RAM, FOUR MEGABYTES!!! It took me FIVE YEARS to edit this post... dear oh dear...

Make that FOUR GIGABYTES please...

Currently Playing:
Celeste and Electronic Super Joy

4 (edited by parasti 2009-05-18 10:09:34)

Re: Nuncabola

Hey, you could not have been more specific if you just used "parasti is a failure" as the name...

Do you know why I released 1.5.0 the way it was?  After 4 years of waiting for someone to release a successor to 1.4.0, I realised it won't happen because there was no-one but me.  In fact, I noticed that a lot of things didn't happen, bugs weren't fixed, and features weren't added, unless I did it.  I found myself in a position I never asked for and was never qualified for, basically maintaining a piece of code in which to this day I struggle to find my way around.  It was anything but fun.  After rewriting the replay mechanism (the patch was a piece of crap, by the way, because that was the only way I could ever finish it, but I doubt anyone noticed) it was clear to me that I could not address all the issues scheduled for 1.5.0 and nobody else would do it.  So I made a decision between letting go of the time and effort I had invested in the game and moving on to something else, or taking matters into my own hands and releasing 1.5.0 in a desperate attempt to attract some long deserved attention and (if I'm lucky) contributors.  Perhaps I made the wrong decision.

Of course, the paradox here is that if instead of standing by and contemplating a fork+rewrite of the game, you would have invested that knowledge, skills and effort of yours in Neverball, 1.5.0 would not have been such a disappointment.  Or maybe you did, and I failed to notice or acknowledge, but I'd prefer that any social/communication problems be discussed up front rather than being a secondary topic in the announcement thread of a fork.

5

Re: Nuncabola

Having said that, I do hope to see some constructive discussion arise from this.  For what it's worth, Nuncabola appears to work on GNU+Linux if I download LWJGL and copy the files from jar/ and native/linux/ subdirectories into the game directory.

6

Re: Nuncabola

OK that's one surprise. Well - I've got a few questions, just out of interest, and I am not making any comment about quality or something because honestly I have no idea.

If I understand correctly, the Nuncabola version is based on a recent trunk version, ie for example the new(est) replay mechanism is already implemented?

What exactly is the advantage over NB except for the timestep, are the libraries that you use now faster or do they have more features, or differently asked, why didn't you just change the timestep and leave the rest as it was?

And, what were the reasons that you decided to release a "personal version" (whatever that is) instead of, for example, proposing a patch that changed the behavior to your liking and asking for opinions?

7

Re: Nuncabola

You can test it easily on Mac OS X too.
You just have to download LWJGL, get native libs from native/macosx and jar from /jar, copy those files in Nuncabola directory and launch the jar file (like on Linux from what parasti said before).

I'm quite surprised about performance as I get on ly around 10% fps frop between Neverball 1.5.1 and Nuncabola 0.1 so Java implementation is not bad tongue

About I have to say about lockstep graphics it's a lot smoother, what a pleasure smile But I don't test more than playing a few levels.

What about the future of Neverball, if this implementation fix some problem can't we backport the behaviour in trunk ?
As Nuncabola is a fork and synchronization with Neverball seems difficult as its language and internals are totally different, which one will get the attention of future development ? ...

8

Re: Nuncabola

themacmeister wrote:

Check here for alpha-transparency icons under LWJGL -> http://www.jmonkeyengine.com/jmeforum/i … pic=3300.0

From reading the web page you linked to, it appears that their discussion is about exposing LWJGL's icon functionality in their LWJGL-based game engine, not about getting alpha transparency to work right in LWJGL itself. Actually, I'm already providing the right alpha data to the right method, the library just seems to reduce it to on/off transparency when passing the icons to Windows. I'm sure it will be fixed eventually. It's not a big deal.

Good Luck, and GREAT WORK!

Thanks, macmeister.

9 (edited by Elviz 2009-05-18 22:52:42)

Re: Nuncabola

nue wrote:

If I understand correctly, the Nuncabola version is based on a recent trunk version, ie for example the new(est) replay mechanism is already implemented?

Yes. Replays should be compatible in both directions.

What exactly is the advantage over NB except for the timestep, are the libraries that you use now faster or do they have more features [...]

The advantages for end-users can be found in the list of changes posted above. If you don't mind the dependence on a JVM and the current lack of an installer, and can live with an English-only application, you may benefit from giving Nuncabola a try.

As for the libraries, I don't see any significant advantages (nor disadvantages, for that matter). One point worth mentioning is that Java offers a timer with better-than-millisecond precision which does make a difference. Another would be OpenAL's support for 3D positioning of audio sources. Though not used currently, I have some rough ideas how it could be employed in the future (think of associating sound effects with path corners, for example for the thwomps in mym's rainbow level).

[...] or differently asked, why didn't you just change the timestep and leave the rest as it was?

Adding interpolation to the timestep required splitting the solid data into a part that changes during the game, and a part that doesn't. This in turn required changes to many other parts of the program.

It was pretty much clear to me from the start that if I ever started serious work on the code, this would have to go along with turning the structure into something that appealed to me. There was no way I would spend my spare time fiddling around with the existing Unix-centric C codebase. Mind you, this may all come down to personal preference. While I did write stuff in C in the mid-90's, these days I prefer different approaches to developing software whenever available.

For low-level code, C still has a slight edge over Java (what with stack allocation of objects and const). However, most of Neverball consists of parts that I feel can be done better and more elegantly with high-level code such as the one Java allows you to write.

And, what were the reasons that you decided to release a "personal version" (whatever that is) [...]

"Personal" refers to the fact that in the end Nuncabola has, as rlk would say, a target audience of one: me. If more people find it useful –and I hope they do– that's great. That's why I made it public. However, in case some will say "Why didn't you implement X?", "I don't like change Y" or "This will never run on mobile phones!", the answer is, it's the way it is because that's what works best for me. Anyone is free to take the code and adapt it to his needs, just as I did.

[...] instead of, for example, proposing a patch that changed the behavior to your liking and asking for opinions?

Well, nothing prevents you from seeing the whole thing as an elaborate patch. And it looks like the opinions have already started coming in.

I'll reply to parasti's posts later.

10 (edited by themacmeister 2009-05-19 01:47:23)

Re: Nuncabola

Elviz wrote:

From reading the web page you linked to, it appears that their discussion is about exposing LWJGL's icon functionality in their LWJGL-based game engine, not about getting alpha transparency to work right in LWJGL itself.

I think if you read some comments from further down the page, alpha transparency issue is solved, and code provided... ?!

I could also be mistaken... ?! smile

Currently Playing:
Celeste and Electronic Super Joy

11

Re: Nuncabola

parasti wrote:

Of course, the paradox here is that if instead of standing by and contemplating a fork+rewrite of the game, you would have invested that knowledge, skills and effort of yours in Neverball, 1.5.0 would not have been such a disappointment.

Actually, I didn't have any plans for a fork, let alone secret ones, until after 1.5 came out. It was only then that I decided to start writing code and see where that would take me.

The thing is, I came to Neverball as a player. I don't feel the need to get involved in the development of every piece of software I use. I would have been happy to continue using my resources for level creation and the odd Nevertable record, with other people handling the code, as Neverball 1.5-dev more or less worked for me.

Until lockstep came along, that is. Clearly that was a good-faith effort at improving things but at the same time it introduced serious new problems. I pointed out the graphics stutter a mere 78 minutes after rlk had made his post. Comments about issues like replay robustness and camera changes followed. I thought the response to my bug reports was unreasonable (1, 2) and certainly did nothing to compel me to help out. Either way, it appeared to me that rlk would be forced to fix the bugs sooner or later. As predicted, the replay mechanism had to be changed again, and, thanks to your work, eventually was.

Unfortunately, the same was not true for the graphics. I found out about the NVIDIA driver issue last December after making some tests, but that only covered one aspect of it, with the real problem being inherent in the lockstep code. At the time I was still convinced that 1.5 couldn't possibly be released in this state. When that did happen –after the judder had suddenly been downgraded from "quite disturbing" to "not a show-stopper"–, continued maintenance of my pre-lockstep build was no longer viable.

This basically left me with two options: giving up on Neverball, or fixing the problem myself. Considering the time I had invested in the creation of Nevermania, I decided against the first option and went with the second. Reading your comments, this situation should sound familiar to you.

Or maybe you did, and I failed to notice or acknowledge, but I'd prefer that any social/communication problems be discussed up front rather than being a secondary topic in the announcement thread of a fork.

Frankly, that's intentional. I much prefer moving forward and getting things done to getting bogged down in drawn-out discussions that sooner or later tend to be dominated by issues other than the topic at hand. I did consider posting some thoughts in the days before the 1.5 release, but in the end concluded that I had already made my views sufficiently clear in the past and that additional whining wouldn't accomplish anything. Which is where the real value of free software kicks in by giving you independence from the decisions of others.

Oh, and you're most definitely not a failure. But I'm sure you were already aware of that. wink

12 (edited by parasti 2009-05-19 19:53:57)

Re: Nuncabola

After getting over the initial surprise, I was worried that my comment would provoke an aggressive-defensive sort of reaction;  I'm happy to see it didn't.  smile  Thanks for the calm and reasoned response.

I actually don't have much to add.  I admit that in a strange way I feel both inspired to work more on Neverball to catch up with those bug fixes and features, and relieved, because I don't really have to since there's already another "Neverball implementation" (which for me is an eye-opening concept in itself) that has all that.  And it's maintained by someone who is an active Neverball player and mapper, one of which I haven't been for a very long time (though, like you, I started as a player, and only became involved in development out of desire to see a new release) and the other I never was.

Let's see what happens.

13

Re: Nuncabola

Very impressive and surprising work Elviz.

Nuncabola 0,1 works fine on my Linux / Ubuntu after having copied LWJGL Linux native libs into the Nuncabola's dir.
The FPS counter surprisingly displays the exact same value than with the last Neverball version! (test in 800x600, RdF 1)

I only have a few Linux specific warning messages at start (I don't have any joystick):

Failed to open device (/dev/input/event0): Failed to open device /dev/input/event0 (13)

10 messages, from event0 to event9, ended by "Linux plugin claims to have found 0 controllers",

Nuncabola's birth is very exciting while rising a lot of questions in my mind, regarding the future of it and of Neverball.
As Parasti says, "Let's see what happens."

BTW, the next week I'll present the project Neverball to my research team (an unusual request of my tutor), and I think Nuncabola will be a good example of things that may happen within an international Internet community gathered around an open source software.

14

Re: Nuncabola

mym wrote:

I only have a few Linux specific warning messages at start (I don't have any joystick):

Failed to open device (/dev/input/event0): Failed to open device /dev/input/event0 (13)

10 messages, from event0 to event9, ended by "Linux plugin claims to have found 0 controllers"

These warnings come from JInput, the library that's used for access to game controllers. Not sure if they are simply caused by the missing joystick or if your user account does not have permission to read those device files. On Windows I have so far only seen similar warnings when unplugging my gamepad while the program is running.

While these messages are harmless, I cannot prevent JInput from printing them without making changes to the library itself. However, what I can do is temporarily redirect the output for certain calls so it does not reach stdout.

BTW, the next week I'll present the project Neverball to my research team (an unusual request of my tutor), and I think Nuncabola will be a good example of things that may happen within an international Internet community gathered around an open source software.

Indeed, that's probably a good point to add to your presentation.

15

Re: Nuncabola

Nuncabola 0.2

  • JInput log messages are now suppressed

  • Packaging tweaks

16

Re: Nuncabola

No native LWJGL libs for non-Windows systems?

17

Re: Nuncabola

parasti wrote:

No native LWJGL libs for non-Windows systems?

No, not yet. Still thinking about the best solution... Mixing them in with the Windows libraries seemed kind of odd. Ideally, there would be a separate Nuncabola download for each platform. However, creating and uploading six different zip files for every new release doesn't sound terribly appealing (binaries+data and binaries only, times three platforms). Alternatively, I could offer separate downloads for the libraries, but that would require users to download two files instead of one.

On an unrelated note, what JVM/JRE do you have installed? Something Sun-based or along the lines of Kaffe+GNU Classpath? Does it have 1.6 compatibility, and how is performance?

18

Re: Nuncabola

I don't think it would be so odd to mix linux / windows / Mac OS X libraries. Those libs are not very big files...

One of the advantage of java is to provide one package which work everywhere. Here Nuncabola is using one native lib, LWJGL, and providing all versions is not a big deal so take it easy in my opinion.

19

Re: Nuncabola

Elviz wrote:
parasti wrote:

No native LWJGL libs for non-Windows systems?

No, not yet. Still thinking about the best solution... Mixing them in with the Windows libraries seemed kind of odd.

You could keep them in a subdirectory and configure the VM to look for native libraries there.  (At least I think you can, based on what I saw in the LWJGL docs.)

On an unrelated note, what JVM/JRE do you have installed? Something Sun-based or along the lines of Kaffe+GNU Classpath? Does it have 1.6 compatibility, and how is performance?

It's the openjdk-6-jre package from Debian:

$ java -version
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.5pre) (6b14-1.5~pre1-5)
OpenJDK Client VM (build 14.0-b10, mixed mode)

From the few comparisons I did, I'd say the performance is a bit worse than a non-optimized build of Neverball.  Almost everything seems to take a little bit longer to load (with the exception of level restarts), but I haven't noticed any difference when playing.  Adventure manages to drop my FPS down to < 1 after picking up a grow coin, but that's consistent with a debug build of Neverball...

20

Re: Nuncabola

You mean it doesn't run on a cell phone? Worthless.


wink big_smile

21

Re: Nuncabola

shino wrote:

One of the advantage of java is to provide one package which work everywhere. Here Nuncabola is using one native lib, LWJGL, and providing all versions is not a big deal so take it easy in my opinion.

You're right, shino. The portability gains of simply including the libraries for all platforms outweigh any drawbacks. The additional files amount to no more than ~700KB when zipped; I'll add them for the next version.

22

Re: Nuncabola

parasti wrote:
Elviz wrote:

[platform-dependent libraries]

You could keep them in a subdirectory and configure the VM to look for native libraries there.  (At least I think you can, based on what I saw in the LWJGL docs.)

Yes, that's about right. Normally, native binaries need to be on the java.library.path (which cannot be set from within the code) but they can also be loaded from a given filename. Luckily, both LWJGL and JInput let the caller specify the path used to construct that name. (Actually, I'm already making use of this to allow the program to be started from outside the game directory without additional configuration.)

On an unrelated note, what JVM/JRE do you have installed? Something Sun-based or along the lines of Kaffe+GNU Classpath? Does it have 1.6 compatibility, and how is performance?

It's the openjdk-6-jre package from Debian: [...]

From what I've read, most parts of the OpenJDK come from (and thus are identical to) the code Sun uses in its "official" JREs so general compatibility should be pretty good. Apparently, they have replaced the proprietary font engine with FreeType so I'd expect the rendered text to look rather similar to Neverball's.

From the few comparisons I did, I'd say the performance is a bit worse than a non-optimized build of Neverball.  Almost everything seems to take a little bit longer to load (with the exception of level restarts), but I haven't noticed any difference when playing.

JVM startup and class loading do add a bit of overhead, no doubt about that. Would you say it's in the realm of the acceptable, taking into account Neverball's performance on the same system? (It certainly is on the machines I've tested Nuncabola on.)

Adventure manages to drop my FPS down to < 1 after picking up a grow coin, but that's consistent with a debug build of Neverball...

That's all part of my evil scheme to prevent players from ever completing Nevermania... tongue

23

Re: Nuncabola

Dave wrote:

You mean it doesn't run on a cell phone? Worthless.


wink big_smile

I don't even have a cell phone! Either way, those have to wait. I'm already spending all my time porting Nuncabola to a Nintendo Game & Watch...

24

Re: Nuncabola

Nuncabola 0.3

  • Downloadable archives now include native libraries for Linux and Mac OS X

  • Packaging tweaks

25

Re: Nuncabola

lol ROFL - Game & Watch lol

Wait a second, I owned heaps of them yikes

Currently Playing:
Celeste and Electronic Super Joy