This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Builderboy
1
« on: January 16, 2015, 10:51:18 pm »
Looks amazing, great work The only thing I would suggest is to look into the actual potential of energy balls in terms of using them for puzzles. There is a reason they were removed in Portal 2, I feel that they were one of the least entertaining elements and give rise to puzzles that end up being a lot more twitch based and frustrating.
2
« on: November 24, 2014, 05:16:44 am »
Nice progress! You said the bumping handles when the portal would hang off a wall, or when it would be inside another portal. Does it also account for when a placed portal would be inside a wall? From the screenshot it would seem so, but it is hard to tell haha. What method did you end up using for the portal bumping?
3
« on: November 08, 2014, 08:28:53 pm »
If you make the portals snap to the 5x5 grid wouldn't that sometimes end up with some weird situations. Like standing above a floor and shooting down, and even though there is plenty of open space the portal still jumps to the left or to the right of your player?
4
« on: November 08, 2014, 06:45:25 pm »
Aw didn't show any screenshots of the dude going through the portal? Also it looks like you are planning to have the portals 5 pixels wide, what made you decide to use those dimensions?
5
« on: November 06, 2014, 05:22:01 pm »
Yes, just make sure that that only works if you do NOT compile it as an app and that you would change program code if you were to accidentally write too far than you setted your area
Note that it does NOT work if you use the Asm() command to run the program from the homescreen. When a program is run it is copied to a new location in memory to be executed, after the program is finished the TiOS does NOT copy it back, and so changes made to the program will not be saved. If you use a shell such as DoorsCS or MirageOS however, they will copy the changes back to the original files location (possibly also if the program is in archive too!) and the changes will be saved.
6
« on: November 06, 2014, 12:29:05 am »
There won't a way to port the levels from the Basic game, since portals worked completely differently in that game. Portals couldn't be inside of walls, they were in empty space instead. There was no momentum or anything like that either, so I imagine the puzzles wouldn't port over particularly well anyway. Also, how is progress on this going?
7
« on: October 18, 2014, 06:28:10 pm »
Well I wish you good luck and hope that the portal bumping all works out well
8
« on: October 18, 2014, 04:29:35 pm »
I'm interested to see how you implement portals. Are you planning for anything like portals on diagonal surfaces? Also are you aware of the portal bumping problem? It was probably the hardest problem to solve in my old portal game and resulted in a ton of code, and still has a number of small bugs.
9
« on: January 09, 2014, 09:04:38 pm »
One weird effect of storing all of the particles this way is that you can introduce biases based on the direction you loop through the field. This probably isn't as much of a problem since you are using some bit tricks instead of simulation each pixel individually. But I have noticed that for example if you want a lot of stacked particles to fall down, the behavior is very different depending if you loop up through the pixels or down. If you loop down, each particle in the stack will "get in the way" except for the one at the bottom, and it will take a fair amount of time for them all to start falling, and they will also end up all spread out. If you loop up however, this effect does not happen, since at each row, the one below it has already been simulated. Something similar also happens if you have particles randomly moving left or right, they will tend to "drift" in one direction depending on how the looping happens.
Additionally, I would like to know how exactly the bit tricks you used to make the physics fast works? It sounds quite tricky and awesome.
10
« on: December 25, 2013, 11:51:50 am »
My awesome parents got me a Portal Prelude mousepad for Christmas!!
11
« on: October 14, 2013, 01:21:41 pm »
If you are still open for trying out water physics, you could always use some type of cellular automata as detailed in a Physics Post I made a while back.
12
« on: October 08, 2013, 05:18:42 am »
A good example of why this would break down is that you could no longer do things like If (I>1) and (A=2), since the 'and' operator is bitwise instead of boolean the conditional would never pass if I is 4 for instance.
13
« on: August 30, 2013, 02:18:54 am »
Hmm I can think of a couple different ways to *almost* do the same thing, but not quite
14
« on: August 29, 2013, 11:21:15 pm »
What kind of problems are you having developing an algorithm yourself? Also depending on the application you are using it for, there might be some additional tricks that you could use if the restrictions were changed slightly.
15
« on: August 16, 2013, 08:53:14 pm »
And when you have one tile, you do that: type_of_tile_with_first_bit_set_at_one This way, you don't waste space when you have a single tile and you save space when you have more than one.
I just wanted to point out that you do indeed waste space when you have a single tile. You waste exactly 1 bit of space That may not seem like a lot, but it can add up depending on your data, you can't every get compression for free.
|