Hi !
Featured games (84)
games approved by the League of Dukes
Games in Showcase (603)
Games in Android Showcase (171)
games submitted by our members
Games in WIP (651)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: 1 ... 8 9 [10]
 on: 2015-07-30 20:29:39 
Started by erikd - Last post by Roquen
Because all FP computations while these modes are active are ignoring denormals. That's outside of the JVM's spec.  Additionally any routine that depends on the behavior of denormals will be effected.  The CPU and OS take care of limiting the mode changes to the thread(s) in question.

 on: 2015-07-30 20:16:48 
Started by erikd - Last post by ags1
Can't you change the scale of your calculations?

 on: 2015-07-30 20:15:10 
Started by erikd - Last post by erikd
In what sense it is a no-no?
I mean I understand why floating point denormals exist and why they are a good thing, but I just want to change the behavior for my particular case.

 on: 2015-07-30 20:11:55 
Started by philfrei - Last post by philfrei
[Edited 7/30/15]
Thanks for the article link! Nice to see some confirmation and clarification. I am also interested in ideas for a good power curve for panning. For now, I'm just using two linears, in reverse directions, one for each channel, with the plan to work on a better version if/when I get into true 3D or another situation that demands power balancing throughout the panning range.

I went through a process of trial an error for the carrier and modulator power curves, testing by ear. The "VolumeMap" object I created can have its LUT (similar in implementation to what I posted on the 'fastest sin' thread) populated by any number of methods. This made it pretty easy to swap the various maps in and out for comparison purposes. The ones that I implemented and compared follow:

  • reverse cos  : 1 - cos(x) where x [0..PI/2]

All of the rest, x goes from 0 to 1:

  • linear
  • 2^x - 1
  • (10^x - 1) / 9
  • (20^x -1) / 19
  • x^e
  • x^2
  • x^3
  • x^4
  • x^5
  • x^6
  • x^7
  • x^10

and a few miscellaneous experiments that didn't work out at all.

I compared the results, by ear, with numbers plugged into the Yamaha DX7 or Native Instruments FM7. I don't consider my choices "final" answers.

I recall x^4 (the article's "overall best") was pretty good, but I guess I am working with a larger dynamic range, hence using the higher exponent values. I remember being indecisive between x^5 and x^6 early on. Lately, I just start with the two I mentioned and try others only if I am have an audible goal in mind. For example some patches, x^7 seems to work better than x^6. The times x^7 works best are patches where the envelope levels are transitioned via "EXP" curves rather than linearly in the "parent" synth.

Thanks to this discussion, I just found another option to try: mapping derived from a Bessel function. Check out the following link, "Appendix B: Bessel Functions" from Dave Benson's book on music related mathematics.

At the very end of this appendix section is a table, with the caption:
The following table shows how index of modulation (z) varies as a func-
tion of operator output level (an integer in the range 0–99) on the Yamaha
six operator synthesizers DX7, DX7IID, DX7IIFD, DX7S, DX5, DX1, TX7,
TX816, TX216, TX802 and TF1

I don't know much at all about Bessel functions, or even if this table arises from Bessel functions other than that it is in the "Bessel" appendix. In this table, I take it that 1.0 is one complete modulation cycle. To be more concrete: I have a sin LUT of 1024. An offset of 360 degrees would be once through the sine table, so a modulation index or amplitude of 1024 in my OpPML should correspond to the DX7S modulation index value of between 69 and 70. This rings true for the patches I've recreated. I'm going to have to confirm. I'm also going to have to experiment with using this table (with linear interpolation) for the modulation values that arise by applying the envelope to the modulation index.

Envelopes should be pretty much the same as they are for subtractive synthesis or wave-table synthesis. Yes? No? I'm assuming you are using outputs that range from 0 to 1 and are multiplied in (but with a power curver). I assumed you have already implemented that sort of thing. I recall a JGO post with you and "AngryOctopus" (ShannonSmith), exchanging links to software synthesizers you had each made.

I think I have a pretty nifty envelope working (updates every frame), but am curious how you do it, and possible improvements.

 on: 2015-07-30 20:11:33 
Started by erikd - Last post by Roquen
It's officially a no-no to muck with flags like this.  It worked the last time I checked.

 on: 2015-07-30 20:02:02 
Started by Archive - Last post by Roquen
Bubble sort works and is simple.  But that's a bad example because sometimes bubblesort is a good choice.

 on: 2015-07-30 19:34:45 
Started by Archive - Last post by NoxInc
SAT is almost never a good idea.  It's only upsides is that it works and it's simple to implement.

So what's bad about it when it works and is simple to use?

 on: 2015-07-30 18:54:36 
Started by erikd - Last post by erikd
Thanks for your reply! Smiley
That was exactly my understanding of it, but I wasn't sure if it would actually work in the context of a JVM.

 on: 2015-07-30 18:47:21 
Started by erikd - Last post by Roquen
You'd need a native method to set denormals-as-zero or flush to zero mode for the thread(s) in question.  Call once and then not worry about it again. 

 on: 2015-07-30 18:39:36 
Started by erikd - Last post by erikd
I'm working on a project where float denormals have a big impact on performance.
To clarify, float denormals are floating point numbers that are so close to 0 that its format isn't well supported by the CPU anymore, leading to incredibly slow performance.
Any floating point calculations that tend to gradually go towards 0 are potentially impacted. In my case, that's audio DSP stuff, but I can imagine that things like physics calculations are potentially affected too.
(For reference: and also the javadoc of Float.MIN_NORMAL).

Currently, I either add a small offset or add a check to 'nudge' these values to 0 (the latter is surprisingly often faster than adding an offset), but that is both impractical in a lot of cases and has a performance impact in itself.

It seems it's possible to disable float denormals on the CPU so that such numbers simply become 0 (the linked article touches upon this), so I'm thinking of creating a little dll and JNI library to do that in java.
I think it would help my project tremendously, and I guess it could be a nice exercise for me.

Now my question is: Is it actually possible, especially within the context of a JVM? I mean I'm quite out of the loop of native programming, so maybe I'm unaware of something that might make this a no-go?
Or maybe something like this already exists somewhere? (I've googled, but I couldn't find anything myself).

Pages: 1 ... 8 9 [10]
SHC (11 views)
2015-08-01 03:58:20

Jesse (17 views)
2015-07-29 04:35:27

Riven (38 views)
2015-07-27 16:38:00

Riven (19 views)
2015-07-27 15:35:20

Riven (22 views)
2015-07-27 12:26:13

Riven (12 views)
2015-07-27 12:23:39

BurntPizza (32 views)
2015-07-25 00:14:37

BurntPizza (43 views)
2015-07-24 22:06:39

BurntPizza (25 views)
2015-07-24 06:06:53

NoxInc (31 views)
2015-07-22 22:16:53
List of Learning Resources
by gouessej
2015-07-09 11:29:36

How Do I Expand My Game?
by bashfrog
2015-06-14 11:34:43

List of Learning Resources
by PocketCrafter7
2015-05-31 05:37:30

Intersection Methods
by Roquen
2015-05-29 08:19:33

List of Learning Resources
by SilverTiger
2015-05-05 10:20:32

How to: JGO Wiki
by Mac70
2015-02-17 20:56:16

2D Dynamic Lighting
by ThePixelPony
2015-01-01 20:25:42

How do I start Java Game Development?
by gouessej
2014-12-27 19:41:21 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‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!