Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (741)
Games in Android Showcase (225)
games submitted by our members
Games in WIP (823)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 191 192 [193] 194
  ignore  |  Print  
  What I did today  (Read 2037601 times)
0 Members and 1 Guest are viewing this topic.
Online princec

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5760 - Posted 2017-10-20 10:30:12 »

Once again I find myself using @Roquen's Grab Bag of curiosities in earnest for a project.
A fantastic resource and many thanks again.

I'm using LCG64 to get a reliably random and speedy sequence of numbers needed to generate some terrain for Battledroid. @theagentd and I will reveal all in a few weeks. (Yes, he is once again enslaved).

Cas Smiley

Offline philfrei
« Reply #5761 - Posted 2017-10-20 22:39:34 »

Non-Java, but programming related: I received my first paycheck yesterday from a startup I have been working with (with request not to deposit it until tomorrow). Not much money, but they are basically paying me to learn as I go and giving me valuable work experience. Project involves VR (using JavaScript / AFrame library).

We had a meeting yesterday where I had to show work done so far. Fortunately, I think I chose well and got a few key things working very smoothly, rather than trying to do too much. For example, an animation (fade to black) for transitioning between "rooms" that people neither noticed or remarked about, as it was glitch free (not easy to achieve).

Museum staff felt good enough about the progress that my boss was approached about working on a grant for an additional project, which pleased him immensely.

I want to comment on JavaScript and on adding operator overloading to Java.

With physical work, (e.g., involving sacks of cement, say), the size of the bags have evolved to something that an good strong male worker can hoist around (I'm thinking of the 100# bags I dealt with, years ago). Now, if the work force were of people of smaller physical stature (e.g., included many women), it would be more efficient if the bags were sized to a slightly lower maximum. Does this make sense?

The point I want to make is that there is a mental correlation: working memory (similar but not to be confused with short-term memory). Young brains can juggle more items at one time than older brains. Maybe I can only track 5 or 6 thoughts at the same time, rather than 8 or 9 like a twenty-something programmer. I think it must be tempting to push the limits of what one can juggle. But having too much stuff to keep track of at the same time ends up being counter-productive. Operator overloading, it seems to me, adds to the load on human "working memory." A better form for the leveraging of complexity is via "chunking," which I take as encapsulating or grouping functionality in a single entity (e.g., a class, a function, a subroutine).

I don't often see discussions about the merit of languages talk much about the human "working-memory" demands of that language.

JavaScript makes pretty high demands, it seems to me. I'm still not able to easily tell something that is usually pretty obvious in Java: a given variable's scope and whether its use in a statement is subject to closure or not. Maybe you've seen the articles on "favorite interview questions" as examples. I can link one if needed. I truly hope Java doesn't go down the path of adding functionality that increases the human working-memory load.

music and music apps: http://adonax.com
Offline theagentd
« Reply #5762 - Posted 2017-10-21 23:28:53 »

Life's been tough on me the last few weeks, especially the last few days, so I decided to do some extra fun coding this weekend.

3-4 years ago I made some threads about an extreme scale space game with realistic Newtonian physics. The game would require simulating a huge number of objects affected by gravity, with extreme speed collision detection. I am talking 100k+ ships, each orbiting a planet at 10km/second, with accurate collision detection. The technical challenges are enormous. After some spitballing here on JGO, I ended up implementing a test program using fixed-precision values (64-bit longs) to represent positions and velocities to get a constant amount of precision regardless of distance from origin. Simple circle-based collision detection was handled by sorting the ships along the X-axis, then checking collisions only for ships that overlap along the X-axis. The whole thing was completely multi-threaded, and I even tried out Riven's mapped struct library to help with cache locality. Even sorting was multithreaded using my home-made parallel insertion sort algorithm, tailor-made for almost-sorted data sets (the order along the X-axis did not change very quickly). It scaled well with more cores, but was still very heavy for my poor i7.

I realized that the only way to get decent performance for this problem on a server would be to run the physics simulation on the GPU. With a magnitude higher performance and bandwidth, the GPU should be able to easily beat this result as long as the right algorithms are used. The physics simulation is easy enough as it's an embarrassingly parallel problem and fits perfectly for the GPU. The collision detection (sorting + neighbor check) is a whole different game. GPU sorting is NOT a fun topic, at least if you ask me. The go-to algorithm for this is a parallel GPU radix sort, but with 64-bit keys that's very expensive. Just like my parallel insertion sort algorithm took advantage of the almost-sorted nature of the sorting, I needed something like that that could run on the GPU as well. That's when I stumbled upon a simple GPU selection sort algorithm.

The idea is simple. For each element, loop over the entire array of elements to sort. Calculate how many elements that should be in front of this element. You now know the new index of your element, so move it directly to that index. Obviously, this is O(n^2), so it doesn't scale too well. However, the raw power of the GPU can compensate for that to some extent. 45*1024 = 46 080 elements can be sorted in ~60FPS, regardless of how sorted the array is. By using shared memory as a cache, performance almost triples to 160 FPS, allowing me to sort 80*1024 = 81 920 elements at 60 FPS. Still not fast enough. Anything above 200k elements runs a big risk of causing the driver to time out and restart...

Enter block-based selection sort for almost sorted data-sets! The idea is to split the list up into blocks of 256 elements, then calculate the bounds of the values of each block. This allows us to skip entire blocks of 256 values if the block doesn't intersect with the current block we're processing. Most likely, only the blocks in the immediate vicinity of each block needs to be taken into consideration when sorting, while the rest of the blocks can be skimmed over. Obviously, this makes the data dependent, and the worst case is still the same as vanilla GPU selection sort if all blocks intersect with each other (which is essentially guaranteed for a list of completely random values). However, for almost sorted data sets this is magnitudes faster!

To simulate an almost sorted data-set, an array is filled with elements like this:
1  
2  
3  
for(int i = 0; i < NUM_KEYS; i++){
   data.putLong(i*8, i + r.nextInt(1000));
}

This gives us an almost sorted array with quite a lot of elements with the exact same value, to test the robustness of the sort. The block-based selection sort algorithm is able to sort a 2048*1024 = 2 097 152 element list... at 75 FPS, way over the target of 100 000. It's time to implement a real physics simulation based on this!



Let's define the test scenario. 1024*1024 = 1 048 576 ships are in perfect circular orbits around the earth. The orbit heights range from low earth orbit (International Space Station height) to geosynchronous orbit. Approximately half of the ships are orbiting clockwise, the other half counterclockwise. The size of the earth, the mass, the gravity calculations, etc are physically accurate and based on real-life measurements.

Going back to my original threaded CPU implementation, it really can't handle one million ships very well. Just the physics simulation of the ships takes 20.43ms, and sorting another 18.75ms. Collision detection then takes another 10.16ms.

The compute shader implementation is a LOT faster. Physics calculations take only 0.27ms, calculating block bounds another 0.1ms and finally sorting takes 2.07ms. I have not yet implemented the final collision detection pass, but I have no reason to expect it to be inefficient on the GPU, so I'm optimistic about the final performance of the GPU implementation.



Each ship is drawn as a point. The color depends on the current index in the list of the ship, so the perfect gradient means that the list is perfectly sorted along the X-axis. 303 FPS, with rendering taking up 0.61ms, 370 FPS without rendering.

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online princec

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5763 - Posted 2017-10-22 14:42:04 »

I await the day when my CPU also has 1000 cores. Surely not too long now.

Cas Smiley

Offline jonjava
« Reply #5764 - Posted 2017-10-22 15:08:17 »

@theagentd

How "realistic" does it have to be, though? Wouldn't something like the Barnes-Hut algorithm be "good enough" for most cases?

http://arborjs.org/docs/barnes-hut
https://en.wikipedia.org/wiki/Barnes%E2%80%93Hut_simulation
http://www.cs.princeton.edu/courses/archive/fall03/cs126/assignments/barnes-hut.html

Offline theagentd
« Reply #5765 - Posted 2017-10-22 19:28:54 »

@jonjava

It's not an N-body simulation. Celestial bodies (stars, planets, moons) affect each other, but ships are only pulled by celestial bodies. Ships don't pull each other either.

Myomyomyo.
Offline jonjava
« Reply #5766 - Posted 2017-10-22 19:56:36 »

@theagentd

Ah, so the scenario is essentially 1 source of gravity where the precise positions of the ships/particles affected by it comes to play? But then why is the calculations so taxing? What makes this so different than anything else? The precision? The magnitude/amount of bodies? Why wouldn't e.g. a QuadTree based solution work?

Offline theagentd
« Reply #5767 - Posted 2017-10-22 21:57:08 »

@theagentd

Ah, so the scenario is essentially 1 source of gravity where the precise positions of the ships/particles affected by it comes to play? But then why is the calculations so taxing? What makes this so different than anything else? The precision? The magnitude/amount of bodies? Why wouldn't e.g. a QuadTree based solution work?
Simulating the physics takes 0.27 ms for ~1 million ship, and this is GPU bandwidth limited, so I an have up to 8 sources of gravity before I get any drop in performance. If it's just the simulation, it can easily be done for over 10 million ships. The problem is the collision detection really. Hierarchical data structures are usually not very efficient on the GPU, and constructing them on the CPU would require reading the data back, constructing the quad tree, then uploading it again to the GPU, which is gonna be too slow. In addition, actually querying the quad tree on the GPU will be very slow as well; GPUs can't do recursion and computations happen in lockstep in workgroups, so any kind of branching or uneven looping will be very inefficient. It's generally a better idea to use a more fixed data structure, like a grid instead, but that's a bad match in this case. The large scale of the world, the extremely fast speed of the ships and the fact that ships will very likely be very clumped up into fleets means that even a uniform grid will be way too slow.

The idea of sorting the ships along one axis and checking for overlap of their swept positions (basically treating each ship as a line from its previous position to its current position) was inspired by Box2D's broadphase actually. I concluded that sorting was a simpler problem to solve than creating and maintaining a spatial data structure (especially on the GPU), but after testing it out more I'm not sure it's a good solution in this case. For a fleet orbiting in close formation, there's a huge spike in sorting cost when the orbit reaches the leftmost and rightmost edges of the orbit when the order of the entire fleet reverses. There are also problems when two large fleets, one moving left and the other right) cross each other, again due to the two fleets first intermixing and then swapping positions in the list once they've crossed... Finally, there's a huge problem with just fleets travelling around together. A fleet of 10 000 ships moving very quickly together will have overlapping swept positions, so all 10 000 ships will be collision tested against each other.

I got a lot of thoughts on this problem, so if you want to have more of a discussion about this, I'd love to exchange ideas and thoughts on this through some kind of chat instead.

Myomyomyo.
Offline jonjava
« Reply #5768 - Posted 2017-10-22 22:21:46 »

@theagentd

Ah, so the scenario is essentially 1 source of gravity where the precise positions of the ships/particles affected by it comes to play? But then why is the calculations so taxing? What makes this so different than anything else? The precision? The magnitude/amount of bodies? Why wouldn't e.g. a QuadTree based solution work?
Simulating the physics takes 0.27 ms for ~1 million ship, and this is GPU bandwidth limited, so I an have up to 8 sources of gravity before I get any drop in performance. If it's just the simulation, it can easily be done for over 10 million ships. The problem is the collision detection really. Hierarchical data structures are usually not very efficient on the GPU, and constructing them on the CPU would require reading the data back, constructing the quad tree, then uploading it again to the GPU, which is gonna be too slow. In addition, actually querying the quad tree on the GPU will be very slow as well; GPUs can't do recursion and computations happen in lockstep in workgroups, so any kind of branching or uneven looping will be very inefficient. It's generally a better idea to use a more fixed data structure, like a grid instead, but that's a bad match in this case. The large scale of the world, the extremely fast speed of the ships and the fact that ships will very likely be very clumped up into fleets means that even a uniform grid will be way too slow.

The idea of sorting the ships along one axis and checking for overlap of their swept positions (basically treating each ship as a line from its previous position to its current position) was inspired by Box2D's broadphase actually. I concluded that sorting was a simpler problem to solve than creating and maintaining a spatial data structure (especially on the GPU), but after testing it out more I'm not sure it's a good solution in this case. For a fleet orbiting in close formation, there's a huge spike in sorting cost when the orbit reaches the leftmost and rightmost edges of the orbit when the order of the entire fleet reverses. There are also problems when two large fleets, one moving left and the other right) cross each other, again due to the two fleets first intermixing and then swapping positions in the list once they've crossed... Finally, there's a huge problem with just fleets travelling around together. A fleet of 10 000 ships moving very quickly together will have overlapping swept positions, so all 10 000 ships will be collision tested against each other.

I got a lot of thoughts on this problem, so if you want to have more of a discussion about this, I'd love to exchange ideas and thoughts on this through some kind of chat instead.

A very insightful clarification covering several levels of analysis, thank you~

My time is limited as of late, not that I'd necessarily be able to contribute anything meaningful to the discussion anyway. But it's an interesting topic I don't think anyone here wouldn't mind seeing more posts of in the future.

Offline Slyth2727
« Reply #5769 - Posted 2017-10-23 22:35:49 »

Messed around with voronoi partitioning today.

<a href="http://www.youtube.com/v/2AFcl7d8p98?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/2AFcl7d8p98?version=3&amp;hl=en_US&amp;start=</a>
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline nsigma
« Reply #5770 - Posted 2017-10-25 15:34:56 »

Just been watching the JDD 2017 Recap video. Pretty pleased with this! Cheesy (a couple of weeks back I did my first conference keynote talk / performance in Krakow - "Write Now, Run Anytime" - about realtime hot code reloading in Java, with lots of audio and visual examples)

<a href="http://www.youtube.com/v/w7f9N-laVW0?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/w7f9N-laVW0?version=3&amp;hl=en_US&amp;start=</a>

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline Apo
« Reply #5771 - Posted 2017-10-26 06:40:44 »

My game calendar menu now with snow AND with "realistic" snow growth. It's very relaxing to watch the snow falling and growing. =)

Offline J0
« Reply #5772 - Posted 2017-10-26 19:15:09 »

It's very relaxing to watch the snow falling and growing
A gif a gif a gif a gif a gif a gif a gif Roll Eyes

Offline dime26

JGO Ninja


Medals: 60
Projects: 7
Exp: 12 years


Should traffic wardens be armed?


« Reply #5773 - Posted 2017-11-06 00:32:09 »

Working on the tutorial series I started, next part is a custom menu:
Click to Play


code https://github.com/tyler6699/evoscape/tree/tutorial_011
Offline MinusKelvin

Senior Devvie


Medals: 20
Projects: 1
Exp: 4 years


Quantum WAT


« Reply #5774 - Posted 2017-11-06 12:47:44 »

I made a lot of progress with a platformer I've been working on. This is my first time implementing a platforming system that isn't both tile based and axis aligned, and I think it's working out very nicely. It's also the first time I've tried implementing moving platforms, and I think I'll be able to get it to handle rotating platforms as well.

Click to Play

gfycat link

You can click my images to look at a larger version most of the time.
Offline dime26

JGO Ninja


Medals: 60
Projects: 7
Exp: 12 years


Should traffic wardens be armed?


« Reply #5775 - Posted 2017-11-06 12:49:47 »

Looks good thus far!
Offline SkyAphid
« Reply #5776 - Posted 2017-11-07 18:35:39 »

Long time no see guys. How is everyone?

We decided to scrap the world generator for a world editor that the players can use too. This is speeding up development by a large margin and will hopefully set Robot Farm apart from other RPGs more. This thing only took like a week to make and can already produce more interesting results than the generator we hacked at for multiple months:




it just werks
Online princec

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5777 - Posted 2017-11-07 18:48:53 »

Procgen is far harder than it looks to make interesting constructs. Hand-crafted is far more time consuming than anyone realises. Having users generate content is almost the best solution except they will also inevitably fill your world with pictures of drippy cocks.

Cas Smiley

Offline SkyAphid
« Reply #5778 - Posted 2017-11-07 19:51:36 »

There's good to be found even in drippy penises being made with your editor, it means someone is using the editor lol

It's actually interesting, the editor still uses some of the generators systems. The world's foundation is made with the generator, then a human will overlay details that are more easily made with hands. So you don't have full control, but enough to change the experience of gameplay.

it just werks
Offline EgonOlsen
« Reply #5779 - Posted 2017-11-07 21:46:45 »

I finally completed the last bits of the first pass of my BASIC V2 to native 6502 machine language compiler (written in Java, of course). It takes a program written in Commodore BASIC V2 (https://en.wikipedia.org/wiki/Commodore_BASIC) and compiles it into an intermediate assembly language that is somehow a bastard child of x86 and 6502 and then something.

For example, this (part of a) BASIC program (an affine texture mapper that I wrote some months ago):

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
....
610 gosub 2400
620 tc%=0
630 for i=0 to 17 step 9
640 t%=0:l%=3:r%=6
650 tt%=0:tl%=2:tr%=4
660 if xy%(i+4)>=xy%(i+1) then 690
670 t%=3:l%=6:r%=0
680 tt%=2:tl%=4:tr%=0
690 rem jump target
700 if xy%(i+7)>=xy%(i+t%+1) then 730
710 t%=6:l%=0:r%=3
720 tt%=4:tl%=0:tr%=2
730 rem jump target
740 t%=t%+i
750 l%=l%+i
760 r%=r%+i
770 tt%=tt%+tc%
780 tl%=tl%+tc%
790 tr%=tr%+tc%
800 dl%=(xy%(l%)-xy%(t%))*di%
810 dr%=(xy%(r%)-xy%(t%))*di%
820 u0%=(ts%(tl%)-ts%(tt%))*di%
830 u1%=(ts%(tr%)-ts%(tt%))*di%
840 v0%=(ts%(tl%+1)-ts%(tt%+1))*di%
850 v1%=(ts%(tr%+1)-ts%(tt%+1))*di%
860 n%=l%
870 if xy%(n%+1)<=xy%(r%+1) then 890
...


gets compiled into this (also partially shown):

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
81  
82  
83  
84  
85  
86  
87  
88  
89  
90  
91  
92  
93  
94  
95  
96  
97  
98  
99  
100  
101  
102  
103  
104  
105  
106  
107  
108  
109  
110  
111  
112  
113  
114  
115  
116  
117  
118  
119  
120  
121  
122  
123  
124  
125  
126  
127  
128  
129  
130  
131  
132  
133  
134  
135  
136  
137  
138  
139  
140  
141  
142  
143  
144  
145  
146  
147  
148  
149  
150  
151  
152  
153  
154  
155  
156  
157  
158  
159  
160  
161  
162  
163  
164  
165  
166  
167  
168  
169  
170  
171  
172  
173  
174  
175  
176  
177  
178  
179  
180  
181  
182  
183  
184  
185  
186  
187  
188  
189  
190  
191  
192  
193  
194  
195  
196  
197  
198  
199  
200  
201  
202  
203  
204  
205  
206  
207  
208  
209  
210  
211  
212  
213  
214  
215  
216  
217  
218  
219  
220  
221  
222  
223  
224  
225  
226  
227  
228  
229  
230  
231  
232  
233  
234  
235  
236  
237  
238  
239  
240  
241  
242  
243  
244  
245  
246  
247  
248  
249  
250  
251  
252  
253  
254  
255  
256  
257  
258  
259  
260  
261  
262  
...
610:
JSR GOSUB
JSR 2400
620:
MOV Y,#0{INTEGER}
MOV TC%{INTEGER},Y
630:
MOV Y,#17{INTEGER}
PUSH Y
MOV Y,#9{INTEGER}
PUSH Y
MOV Y,#0{INTEGER}
MOV I{REAL},Y
MOV A,(I{REAL})
JSR INITFOR
640:
MOV Y,#0{INTEGER}
MOV T%{INTEGER},Y
MOV Y,#3{INTEGER}
MOV L%{INTEGER},Y
MOV Y,#6{INTEGER}
MOV R%{INTEGER},Y
650:
MOV Y,#0{INTEGER}
MOV TT%{INTEGER},Y
MOV Y,#2{INTEGER}
MOV TL%{INTEGER},Y
MOV Y,#4{INTEGER}
MOV TR%{INTEGER},Y
660:
MOV Y,#1{INTEGER}
MOV X,I{REAL}
ADD X,Y
MOV G,XY%[]{INTEGER}
CHGCTX #0
JSR ARRAYACCESS
PUSH X
MOV Y,#4{INTEGER}
MOV X,I{REAL}
ADD X,Y
MOV G,XY%[]{INTEGER}
CHGCTX #0
JSR ARRAYACCESS
POP Y
GTEQ X,Y
CMP X,#0{REAL}
JNE NSKIP19
JMP SKIP19
NSKIP19:
JMP 690
SKIP19:
670:
MOV Y,#3{INTEGER}
MOV T%{INTEGER},Y
MOV Y,#6{INTEGER}
MOV L%{INTEGER},Y
MOV Y,#0{INTEGER}
MOV R%{INTEGER},Y
680:
MOV Y,#2{INTEGER}
MOV TT%{INTEGER},Y
MOV Y,#4{INTEGER}
MOV TL%{INTEGER},Y
MOV Y,#0{INTEGER}
MOV TR%{INTEGER},Y
690:
NOP
700:
MOV Y,T%{INTEGER}
MOV X,I{REAL}
ADD X,Y
MOV Y,#1{INTEGER}
ADD X,Y
MOV G,XY%[]{INTEGER}
CHGCTX #0
JSR ARRAYACCESS
PUSH X
MOV Y,#7{INTEGER}
MOV X,I{REAL}
ADD X,Y
MOV G,XY%[]{INTEGER}
CHGCTX #0
JSR ARRAYACCESS
POP Y
GTEQ X,Y
CMP X,#0{REAL}
JNE NSKIP20
JMP SKIP20
NSKIP20:
JMP 730
SKIP20:
710:
MOV Y,#6{INTEGER}
MOV T%{INTEGER},Y
MOV Y,#0{INTEGER}
MOV L%{INTEGER},Y
MOV Y,#3{INTEGER}
MOV R%{INTEGER},Y
720:
MOV Y,#4{INTEGER}
MOV TT%{INTEGER},Y
MOV Y,#0{INTEGER}
MOV TL%{INTEGER},Y
MOV Y,#2{INTEGER}
MOV TR%{INTEGER},Y
730:
NOP
740:
MOV Y,I{REAL}
MOV X,T%{INTEGER}
ADD X,Y
MOV T%{INTEGER},X
750:
MOV Y,I{REAL}
MOV X,L%{INTEGER}
ADD X,Y
MOV L%{INTEGER},X
760:
MOV Y,I{REAL}
MOV X,R%{INTEGER}
ADD X,Y
MOV R%{INTEGER},X
770:
MOV Y,TC%{INTEGER}
MOV X,TT%{INTEGER}
ADD X,Y
MOV TT%{INTEGER},X
780:
MOV Y,TC%{INTEGER}
MOV X,TL%{INTEGER}
ADD X,Y
MOV TL%{INTEGER},X
790:
MOV Y,TC%{INTEGER}
MOV X,TR%{INTEGER}
ADD X,Y
MOV TR%{INTEGER},X
800:
MOV X,T%{INTEGER}
MOV G,XY%[]{INTEGER}
CHGCTX #0
JSR ARRAYACCESS
PUSH X
MOV X,L%{INTEGER}
MOV G,XY%[]{INTEGER}
CHGCTX #0
JSR ARRAYACCESS
POP Y
SUB X,Y
MOV Y,DI%{INTEGER}
MUL X,Y
MOV DL%{INTEGER},X
810:
MOV X,T%{INTEGER}
MOV G,XY%[]{INTEGER}
CHGCTX #0
JSR ARRAYACCESS
PUSH X
MOV X,R%{INTEGER}
MOV G,XY%[]{INTEGER}
CHGCTX #0
JSR ARRAYACCESS
POP Y
SUB X,Y
MOV Y,DI%{INTEGER}
MUL X,Y
MOV DR%{INTEGER},X
820:
MOV X,TT%{INTEGER}
MOV G,TS%[]{INTEGER}
CHGCTX #0
JSR ARRAYACCESS
PUSH X
MOV X,TL%{INTEGER}
MOV G,TS%[]{INTEGER}
CHGCTX #0
JSR ARRAYACCESS
POP Y
SUB X,Y
MOV Y,DI%{INTEGER}
MUL X,Y
MOV U0%{INTEGER},X
830:
MOV X,TT%{INTEGER}
MOV G,TS%[]{INTEGER}
CHGCTX #0
JSR ARRAYACCESS
PUSH X
MOV X,TR%{INTEGER}
MOV G,TS%[]{INTEGER}
CHGCTX #0
JSR ARRAYACCESS
POP Y
SUB X,Y
MOV Y,DI%{INTEGER}
MUL X,Y
MOV U1%{INTEGER},X
840:
MOV Y,#1{INTEGER}
MOV X,TT%{INTEGER}
ADD X,Y
MOV G,TS%[]{INTEGER}
CHGCTX #0
JSR ARRAYACCESS
PUSH X
MOV Y,#1{INTEGER}
MOV X,TL%{INTEGER}
ADD X,Y
MOV G,TS%[]{INTEGER}
CHGCTX #0
JSR ARRAYACCESS
POP Y
SUB X,Y
MOV Y,DI%{INTEGER}
MUL X,Y
MOV V0%{INTEGER},X
850:
MOV Y,#1{INTEGER}
MOV X,TT%{INTEGER}
ADD X,Y
MOV G,TS%[]{INTEGER}
CHGCTX #0
JSR ARRAYACCESS
PUSH X
MOV Y,#1{INTEGER}
MOV X,TR%{INTEGER}
ADD X,Y
MOV G,TS%[]{INTEGER}
CHGCTX #0
JSR ARRAYACCESS
POP Y
SUB X,Y
MOV Y,DI%{INTEGER}
MUL X,Y
MOV V1%{INTEGER},X
860:
MOV Y,L%{INTEGER}
MOV N%{INTEGER},Y
870:
MOV Y,#1{INTEGER}
MOV X,R%{INTEGER}
ADD X,Y
MOV G,XY%[]{INTEGER}
CHGCTX #0
JSR ARRAYACCESS
PUSH X
MOV Y,#1{INTEGER}
MOV X,N%{INTEGER}
ADD X,Y
MOV G,XY%[]{INTEGER}
CHGCTX #0
JSR ARRAYACCESS
POP Y
LTEQ X,Y
CMP X,#0{REAL}
JNE NSKIP21
JMP SKIP21
NSKIP21:
JMP 890
SKIP21:
...


...which then will be executed by a simple interpreter for that strange pseudo assembly code that I wrote.

Which then results into this:



The next step is to convert this into actual 6502 assembly code and then assemble that (the assembler for that is already done as well) into actual machine code.

Offline cygnus
« Reply #5780 - Posted 2017-11-08 02:28:49 »

New weapon textures:

New view management system:

Basically, you will be able to have as many cameras as you want, wherever you want. They will be able to have waypoints you can teleport back to for even more uninterrupted building. They are all functional, and as you can see, there is an inventory GUI that can be moved around too. That window functionality took another (I think my 4th) rewrite of the GUI system, but it wasn't a total one, thankfully.

I'm currently working on adding a dimension adjuster for the windows so you can resize them.
Offline Slyth2727
« Reply #5781 - Posted 2017-11-08 19:22:17 »

Submitted my first grant application for a research project! I've been planning to release 2 papers a year until my I start my PhD and so far I'm right on track - first semester is almost over and I've got one paper being published soon and another one in the works with this grant. I'll be presenting my first one at a local SIAM conference soon so when that comes up I'll try to get a recording or something maybe. Super excited, I'm loving college.

Edit: some of the things I've worked on over the past week.
<a href="http://www.youtube.com/v/GbQQJXAcgo4?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/GbQQJXAcgo4?version=3&amp;hl=en_US&amp;start=</a>
Offline elect

JGO Knight


Medals: 48



« Reply #5782 - Posted 2017-11-08 20:24:38 »

topics?
Offline Slyth2727
« Reply #5783 - Posted 2017-11-08 22:04:54 »

The second is a study on reinforcement/adaptive learning in humans and machines. I'm taking a look at improving current RL models. The first was on a algorithm I found to quickly and easily bruteforce a portion of  trigonometric integration on a computer. I know bruteforce and quick doesn't usually go together but I derived a neat formula that allows me to do just that. Not huge leaps and bounds in the fields but it's ok for my first published papers. I may post a link to them after they're published if anyone's interested.
Offline dime26

JGO Ninja


Medals: 60
Projects: 7
Exp: 12 years


Should traffic wardens be armed?


« Reply #5784 - Posted 2017-11-10 00:57:13 »

Pixel dailies theme was Cactus, made this:

Offline zngga
« Reply #5785 - Posted 2017-11-10 15:32:47 »

Looks great ^

Do let us know when you have something playable!

My code never has bugs... it just develops unexpected features!
Offline dime26

JGO Ninja


Medals: 60
Projects: 7
Exp: 12 years


Should traffic wardens be armed?


« Reply #5786 - Posted 2017-11-12 00:29:30 »

Finished tutorial 11, this one goes through creating a basic menu with some buttons.

https://carelesslabs.wordpress.com/2017/11/12/making-a-libgdx-roguelike-survival-game-part-11-custom-menu-buttons-gamedev

I will look at saving & loading next, not sure if this "game" will ever be completed but will hopefully encourage someone to make their own game and help start them off on the right track (Or at least a track of sorts). 
Offline KaiHH

JGO Kernel


Medals: 481



« Reply #5787 - Posted 2017-11-12 15:25:28 »

Yesterday and today I've begun writing the first "code-centric" tutorials on implementing an unbiased importance-sampled path tracer in LWJGL 3 with OpenGL compute shaders. The idea of this kind of tutorial is to read Java and GLSL code from top to bottom and have JavaDocs and comments explaining things as you go. The important thing is that you are always in working source code.
I wanted to pick up on the LWJGL3 GitHub Wiki entry I've written in 2014 and write one working version from start right up to implementing filtering algorithms (such as the 2010 Edge-Avoiding À-Trous Filter paper or Nvidia's 2017 spatiotemporal enhancement of it) to make it suitable for real-time rendering.

Tutorial 1 introduces the LWJGL3 and compute shader setup for very simple primary ray raytracing to intersect with geometry
Tutorial 2 adds unbiased Monte Carlo integration of lambertian/diffuse BRDFs
Tutorial 3 adds unbiased importance sampling of diffuse and specular BRDF components to highlight the "importance" of importance sampling for BRDFs which have strong features in certain directions, such as Phong
Tutorial 4 will add "multiple importance" sampling for efficiently sampling (small) light sources

Tutorial 3 with importance sampling:


Tutorial 3 with uniform hemisphere sampling:


Java sources: https://github.com/LWJGL/lwjgl3-demos/tree/master/src/org/lwjgl/demo/opengl/raytracing/tutorial

EDIT: Added Tutorial 4 with Multiple Importance sampling using Eric Veach's "balance heuristic" weighting and the one-sample model (i.e. randomly sampling either the light or the hemisphere).

Tutorial 4 without MI:


and with MI:


Note that this is a completely unbiased solution, so both images will converge to the exact same result (given enough time for the first one of course).
Offline KaiHH

JGO Kernel


Medals: 481



« Reply #5788 - Posted 2017-11-13 21:28:18 »

Added Tutorial 4 today (see above edit).
Offline h.pernpeintner

JGO Knight


Medals: 64



« Reply #5789 - Posted 2017-11-13 21:56:14 »

Veeeeeeeery nice Smiley
Pages: 1 ... 191 192 [193] 194
  ignore  |  Print  
 
 

 
xxMrPHDxx (18 views)
2017-11-21 16:21:00

xxMrPHDxx (11 views)
2017-11-21 16:14:31

xxMrPHDxx (14 views)
2017-11-21 16:10:57

Ecumene (114 views)
2017-09-30 02:57:34

theagentd (148 views)
2017-09-26 18:23:31

cybrmynd (248 views)
2017-08-02 12:28:51

cybrmynd (248 views)
2017-08-02 12:19:43

cybrmynd (244 views)
2017-08-02 12:18:09

Sralse (258 views)
2017-07-25 17:13:48

Archive (878 views)
2017-04-27 17:45:51
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
java-gaming.org 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‑gaming.org
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!