Programming Thread

Started by the-pi-guy, Mar 13, 2016, 10:39 PM

previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Go Down

Legend

What solution did you go with? The solution that popped in my head was imagining a line from 0,0 to N,M on a pixelized grid. Two horizontal pixels next to each other represent a turn for the first unit and two vertical pixels represent a turn for the second unit. Could work with non integer speeds and could work with an arbitrary amount of units.

the-pi-guy

Thinking about it, I described it ambiguously before.

But basically it'd be like chess, if chess players could go more than once based on their speed so if M and N were 28 and 13, the turns would be calculated as:
28, 28, 13, 28, 28, 13

What solution did you go with?
The idea is that you build up a timeline:

Suppose M and N were m/s, then you could take 1 meter / (M) to get seconds.

You do this for the list of units, you sort them in ascending order.  

A.) The first unit in that list would go first. So you remove that one, and add it to the queue.

B.) Then multiply that time by whatever cycle that unit is on. So you calculate when they would make their k+1 move. You add this back into the list, in the place where it stays ordered.

Then you repeat steps A and B until you have the goal number of lookahead steps.

darkknightkryta

So back to my controller to arcade converters.  I managed to find some current sink shift registers, which solves a lot of my issues with hardware for my converter.  Finished up the Linux code for getting controller input, despite the lack of documentation on the controller stuff for evdev (Seriously, I was lucky I found a random post on the internet from someone on the SDL team with a working, useable example).  I managed to get my SPI code working, that I shamelessly took from wiringPi (Rip).  Shiftout worked.  Controller code worked.  I put the two together?  It broke.  Something's up with the way linux or GCC handles loops.  The word I was sending out was getting changed asycrhronously somehow.  So I was investigating multithreading.  Multithreading isn't fun.  I took a chance and copied the word to another variable before the shiftout.  It worked.   (╯°□°)╯︵ ┻━┻

Legend

So back to my controller to arcade converters.  I managed to find some current sink shift registers, which solves a lot of my issues with hardware for my converter.  Finished up the Linux code for getting controller input, despite the lack of documentation on the controller stuff for evdev (Seriously, I was lucky I found a random post on the internet from someone on the SDL team with a working, useable example).  I managed to get my SPI code working, that I shamelessly took from wiringPi (Rip).  Shiftout worked.  Controller code worked.  I put the two together?  It broke.  Something's up with the way linux or GCC handles loops.  The word I was sending out was getting changed asycrhronously somehow.  So I was investigating multithreading.  Multithreading isn't fun.  I took a chance and copied the word to another variable before the shiftout.  It worked.   (╯°□°)╯︵ ┻━┻
Gotta love when there's something fundamental that just doesn't make sense.

A couple days ago I had shader code that was producing impossible errors. Eventually I found out the text itself had an invisible character that was breaking things. Don't know how Unity let that slide vs warning me.

Go Up