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 - Xeda112358
Pages: 1 ... 129 130 [131] 132 133 ... 317
1951
« on: March 31, 2012, 11:42:04 pm »
It works on my calc. Awesome o.o My SE has 48KB, and it really works  In Wabbit, I have issues, though...
1952
« on: March 31, 2012, 11:12:42 pm »
I didn't think this would be accomplished within the next few years, considering how long it took on the 84+ for some people to handle USB programming 
Yeah, that is what I thought. I am glad for this, especially for when I get my hands on an Nspire...
1953
« on: March 31, 2012, 11:09:43 pm »
Yeah, it is definitely one of the most space consuming models, but the plus is that it will run much faster than other methods . Plus, you can have particles occupying the whole screen  Also, since the Prizm has a color screen, you could simplify the method to just having everything on the screen. Just use the colors to figure out which particles are which, then you can use the pressure buffer in combination. Then for a full screen, it would be 41472 bytes for the pressure buffer and whatever buffer the LCD is on 
1954
« on: March 31, 2012, 05:45:47 pm »
Epic o.o I just showed it off to a friend, too o.o Google rocks
1955
« on: March 31, 2012, 04:56:16 pm »
Maybe  Also, I have mine done, saving/loading works, drawing in 2 3 or 4 shades, with other goodies included It will require a readme, though 
1956
« on: March 31, 2012, 04:48:16 pm »
Basically, I am on this kick of using multiple buffers. For example, you have a buffer for water, a buffer for sand, and a buffer for immovable objects. The water moves and it checks above and below. If there is a space below on all buffers, move down. Otherwise, check left/right and do the same trick. If there is still no room, check up. If the sand buffer has a pixel on swap the pixel locations. You then have similar rules for other particles The only issues you might have from there is that you don't easily get pressure or temp involved. For that, you would need to modify the algorithms for each pixel, slightly. Then you can create an array for each pixel on the screen for pressure. If I were doing this, I would do 1 nibble per pixels where each bit in the nibble corresponded to a direction. 1 means pressure in that direction and 0 means no pressure. This would help decide the primary directions for a particle to move and then secondary directions, and further. EDIT: For the Prizm, if we work in a 128x128 region, it would require 2KB per layer and 64KB for the pressure buffer. The Prizm has 2MB, so that should be fine with 10 particle types, that would be 84KB of RAM used.
1957
« on: March 31, 2012, 04:33:58 pm »
Wow, freaking awesome This looks really nice and the type of game that I would like to play (I like puzzles that I didn't create). Great job
1958
« on: March 31, 2012, 04:20:45 pm »
Hmm, if this gets done, you should keep two buffers. The first buffer is the buffer you use to draw. You scan it and compare each byte to the other buffer, if it is different, copy the byte to the other buffer and draw the sprite. This will save speed if the program only needs to change a few tiles at a time and will only lose a few cycles when the whole map needs to be updated.
1959
« on: March 31, 2012, 04:11:57 pm »
Wow, awesome o.o
1960
« on: March 31, 2012, 04:10:26 pm »
I would do camera if you like to take pictures. Your music player is just aesthetically displeasing, but it is still functioning. If you get a new camera, you will be getting more function (I think). Still that depends on how much you want a camera 
1961
« on: March 31, 2012, 04:05:27 pm »
Hmm, too bad the project is now deadish :[ I do have a few particle rules and I was rewriting the particle engine to Grammer, so if you ever pick this up again, feel free to bug me I am currently looking into a method I thought of that will use lots of RAM, but allow for fast interaction with particles (so you can quickly instantly detect if there oil under your water, for example). Unfortunately, the program could require >9000 bytes of free RAM, but it might be worth it... EDIT: Of course, on a Prizm, this would not be a big deal and could allow for about 20 different particle types o.o
1962
« on: March 31, 2012, 03:11:17 pm »
Wow, this is cool o.o
1963
« on: March 31, 2012, 03:03:19 pm »
yeah, that is the best way I can think to do it, though, so maybe keep it to zero, one or two regions per level? Plus, you can make them as big or small as you want and you could even make it a tool for the user and they have only one. When you throw it, it deletes the old one and creates a new one in a different spot
1964
« on: March 31, 2012, 02:58:15 pm »
exactly And like you said on IRC, in this case, it might be okay to include the region in the source itself as opposed to in a separate pic file Plus, you can always use it for an idea in a future game
1965
« on: March 31, 2012, 02:53:32 pm »
Yes, that is right Also, you can make a dampening effect, again, too, by removing velocity or dividing by a constant again, so it eventually stands still.
Pages: 1 ... 129 130 [131] 132 133 ... 317
|
Show Posts