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 - AngelFish
Pages: 1 ... 12 13 [14] 15 16 ... 215
196
« on: January 15, 2012, 05:23:51 am »
I've been working a bit on my own terrain generator for Tinycraft. Here's the latest screenshot, using a new cellular automata generator that operates in 4n^2 time.  It still has some obvious flaws, but it's much better than the old version 
197
« on: January 12, 2012, 04:21:11 pm »
What do you think? What's best to start for someone who doesn't know anything about programming?
That's about the same as asking "What's the best spoken language to learn?" It all depends on how you think and solve problems. Python is good if you like computers and want a computer language that looks like English. Java is good if you want a language that's very safe and prevents you from making stupid errors. TI-BASIC is excellent if you tend to solve problems by reducing them to sets of very simple procedures (just like Assembly). C++ and Perl are good for no one to start off with. Ruby is a nice all-around language with pleasant syntax designed to be friendly. Haskell was designed so that people who are familiar with pure mathematics will have little problem transitioning. You can go on and on about what different languages are good at, but the bottom line is that the best language to start off with is the language that complements your problem solving style (or styles). If you've done a lot of hardware design, then Assembly might very well be the best language to start off with. If you've done a lot of higher level math, then Haskell or Lisp would probably be better. There's no one "best" language for anything, except Assembly for speed/code size.
198
« on: January 07, 2012, 08:28:53 pm »
I personally don't see the point of tracking changes; you're going to have to unarchive and archive each map anyways. It might even be harder and take longer to track just the changes, when you could just overwrite the old map with the new one completely.
The point of the change list is that there's no map to archive/unarchive in the first place. Memory becomes significantly less of an issue when you're *only* storing the blocks or chunks the player has modified. *Chunks would be more memory efficient
199
« on: January 07, 2012, 07:53:43 pm »
Heh, that's almost exactly the 2D case of the algorithm I came up with  As you can see from that demo, the algorithm has some problems if you're not careful, but they shouldn't be noticeable unless you have a large scale view like that.
200
« on: January 07, 2012, 07:33:37 pm »
Actually, you could transfer the map in RAM to an appvar in archive, so changes would be persistent. Keep in mind that we also need to save object data as well (furnaces, workbench, etc.)
Yes but first archiving a huge map is slow  but also, when you want to make a new game, you can only play on the edited map (except if the game recreates it but then the executable will be huge). This is why I thought of an archived and non permanently editable map 
Personally, I don't see why you don't go for the best of both worlds: No statically defined worlds and nothing to save unless the user modifies things. I've thought a bit about this particular problem before and one of the best ideas I came up with was to generate the world in such a way that from any particular point (x,y), one can recover the underlying terrain in any direction. This is actually possible through something known as a reversible RNG. Additionally, as it turns out, you can use something called a fractal algorithm to generate somewhat realistic terrain from such random numbers. Admittedly, I never got around to actually porting the algorithm to Axe, but I probably could if you wanted to do so. As for the "othing to save unless the user modifies things" claim, remember that for most people, the number of things in the world that will be modified is almost certain to be fairly small. Keeping a list of changes in the world would probably be suitable. The McRegion format used by minecraft would be an excellent format to keep track of these changes with some minor modifications.
201
« on: January 06, 2012, 04:12:30 pm »
2.5 seconds for my prizm. I also did a run with 10 trials and averaged it to get basically the same answer. This means, of course, that Casio somehow managed to slow down their code so much that doubling the clock frequency resulted in a calculator only *slightly* slower than the old models 
202
« on: December 29, 2011, 05:49:43 am »
Nah, you probably saw it in my Axe Doom program:
J/k.
I was about to ask why your dithering was so bad until I saw the "j/k" part
203
« on: December 29, 2011, 03:13:03 am »
i think you just have to become a little more realistic.. ndoom and/orwolfenstein in lua is impossible, that language is just too slow (interpreted) to do al that 3D design..
I wouldn't go so far as to say it's impossible. Even 84+ BASIC has a wolfenstein port of somewhat reasonable quality. That said, it wouldn't be nearly as good as a C version could be and would take a lot of skill in the language. If you didn't mind memory usage, you could always take the old Doom cheat and compute lookup tables of almost every possible angle to speed up rendering
204
« on: December 24, 2011, 03:45:12 am »
The download links were removed because the compilations were found to be in violation of the copyrights of one or more of the authors of the software contained therein based on the information provided.
205
« on: December 21, 2011, 04:08:24 am »
Nice project. One bug I noticed is that even if you don't use DispGraph, entering anything in the interactive mode will cause the display to update.
As for the name, what about AXE (Axe eXecutable Environment) or AXiE (Axe eXecuting interactive Environment)?
206
« on: December 19, 2011, 10:19:25 pm »
207
« on: December 18, 2011, 12:11:32 am »
ohh, well I'm not sure where your going, but the idea is it's like an ereader. download books on the calc, the use this program to run them and read.
Then you definitely need to support a common format (such as PDF). Since the 84+ calcs don't have any sort of real filesystem, you'd also need to write a computer side converter to wrap them up as appvars or programs.
208
« on: December 13, 2011, 05:08:58 am »
Well, I personally wonder why they didn't work on such Prizm instead of an old calc redesign that will be a nuisance for a bunch of people?
They're probably working on said Prizm. I suspect that this was a cost cutting measure to use similar boards for different lines of calculators. [/just a guess]
I actually suspect it had to do with licensing and production costs. Their licenses on the old SH-3 chips are probably running out and they're moving their production lines completely over to the newer SH-4 chips which are likely more efficient anyway. It wouldn't surprise me at all to find out that there were a host of other devices running SH chips that were also being converted. In any case, this is a perfect [if somewhat ironic] example of one situation where accessing the hardware directly and not using Casio's OS syscalls is probably more portable than the other way
209
« on: December 12, 2011, 12:50:54 am »
210
« on: December 11, 2011, 11:31:15 pm »
Baidu is the worst of the chinese spambots. It's been acting up lately and eating gigabytes of bandwidth.
Pages: 1 ... 12 13 [14] 15 16 ... 215
|
Show Posts
