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 ... 60 61 [62] 63 64 ... 317
916
« on: June 14, 2013, 12:28:24 pm »
Xeda112358 raises hand
For the water animation, it looks like you are using the cellular automata rule where it moves down if it can, otherwise it tries left or right. I posted a topic somewhere about the effects of adding one more rule. If it cannot move in any of those directions, try to move up. This looks more like it is boiling water and while it still doesn't have the real physics you might desire, it has the neat trait of capillary action. This means if you create a tube, the liquid will defy gravity by going up it (if it is thin enough). It might add another element to the game play.
By the way, it looks absolutely awesome!
EDIT: Er, to clarify, "it" == the game.
917
« on: June 08, 2013, 10:36:11 am »
My routine to draw a 96x64 B/W image using the format that the regular 83/84 calcs have took 308016 t-states to update (about 20FPS at 6MHz).
A routine to just copy a whole image in color is somewhat faster. To make the code small, it would take about 3222600 t-states for a full color image with uncompressed data. Adding a little extra code to make it faster, it can be brought down to 2553600 t-states (about 2.35 FPS).
That being said, the CSE makes it very easy to update only a portion of the screen. so if you have areas of the screen that do not get updated frequently, such as menu items or an HUD, and you cut down how much of the screen is updated to just a 240x240 region, you can draw a 15x15 tilemap of 16x16 sprites at about 3FPS (6MHz) (a single 16x16 sprite, full color, takes about 8512 t-states to draw). You could get 7FPS for a 10x10 tilemap, but then you are only using 160x160 pixels of the screen (half the width, 2/3 the height).
918
« on: June 07, 2013, 07:49:44 pm »
Well, we don't need to worry about constantly refreshing the screen for grayscale, so that might be a boost in speed for grayscale games. LCD updating was always a bottleneck, so that is slightly diminished now that we have a much more responsive LCD to work with (but now we have more pixels to update  ). Plotting pixels should be a whole lot faster (a few hundred times faster,maybe?) and drawing sprites will also be pretty fast, plus we can add a color aspect to them.
919
« on: June 05, 2013, 09:03:20 pm »
Somebody should make a tool for displaying pictures in the B/W format possibly using a customisable pallet and resizing options. Then pictures could still be 768 bytes of data. I know I wrote a quick routine and posted it on Cemetech for just that purpose,so maybe somebody can take it and turn it into a useful program 
920
« on: June 05, 2013, 10:21:54 am »
When you say Archive support, do you mean having the ability to keep files and folders in archive? Currently,if you make any OS pointers, then the OS vars can be archived. An example is if you have prgmSUB01 archived, this will still work:
CD(Sub) ;open the folder Sub.
VPTR(prgmSUB01, 01) ;create an OS pointer to prgmSUB01 named 01 stored in folder Sub.
OPEN(Sub/ 01) ;use the OPEN() command to open the file. The file type is auto detected and opened with the appropriate routines.
I use this technique to keep sub programs in archive. As well, you can have some sub-programs that require different parser hooks, so if prgmSUB01 is a regular BASIC program, but prgmSUB02 needs Celtic 3, prgmSUB03 needs BatLib, and prgmSUB04 needs DoorsCS7, you could do:
CD(Sub)
VPTR(prgmSUB01, 01)
VPTR(prgmSUB02, 02.c3)
VPTR(prgmSUB03, 03.batb)
VPTR(prgmSUB04, 04.dcs7)
As long as the appropriate apps are on the calculator,the programs will run. For a Celtic 3 program, FileSyst first checks if the Celtic 3 app is on the calculator, if it isn't, it checks if DoorsCS7 is on the calculator. If one of them is on, then FileSyst will try to install their hooks and then run the program. From the readme:
/==============================================================\
| OPEN(File) |
\==============================================================/
| This can be used to open files based on its file extension. |
|If it does not have a file association, FileSyst will try to |
|open it as a nostub assembly program or BASIC program. Built |
|in file types and the programs that open them are: |
+======+=======================================================+
|Assoc:| Programs (In descending order of priority) |
+======+=======================================================+
| ION | DoorsCS7,DoorsCS6 |
| MOS | DoorsCS7,DoorsCS6 |
| DCS | DoorsCS7,DoorsCS6 |
| DOC7 | DoorsCS7+DocDE7 |
| BAT | BatLib |
| BATB | BatLib |
| C3 | DoorsCS7,Celtic 3 |
| XLIB | DoorsCS7,Celtic 3,xLIB |
| DCS6 | DoorsCS6,DoorsCS7 |
| DCS7 | DoorsCS7 |
| DCSB | DoorsCS7 |
| OMNI | Omnicalc |
| GRAM | Grammer |
+======+=======================================================+
| For example, if you try to run an xLIB program, FileSyst |
|first searches for DoorsCS7, if that isn't available, it tries|
|Celtic 3 and then xLIB. |
| Further, xLIB and Omnicalc don't have any actual installers |
|aside from manual installation. If FileSyst has to install |
|these, it uses a method that should only work on specific |
|versions, xLIB v.602b and Omnicalc v1.26 and v1.26MP. |
| Now, for some example code: |
| CD(Zeda/Games) ;Change the directory. |
| VPTR(prgmDK5ION, DonkeyKong.ION) ;Makes an OS shortcut. |
| OPEN( DonkeyKong.ION) ;Run DonkeyKong. |
| |
| OPEN() should return to the program properly, but there is |
|always a chance that it won't if an assembly program doesn't |
|quit properly (or if a BASIC program uses Stop). |
\==============================================================/
921
« on: June 03, 2013, 09:13:16 am »
I now have 1 of each of the following (in the order that I obtained them).
TI-84+SE (3 RAM pages, new LCD that supports flipping)
TI-89t
TI-84+ (8 RAM pages, old LCD)
Casio Prizm
TI-84 Pocket.fr
My collection is slowly growing. I got the 84+SE 2009, the 89t in 2010, the 84+ in 2011 (used), the Prizm last year, and the 84 Pocket a few days ago. So my collection grows every year.
922
« on: June 01, 2013, 06:02:04 am »
Kind of  My hope for the program editor is that it can be used for other languages such as BASIC, Assembly, Axe, and Grammer.
923
« on: May 31, 2013, 06:55:30 am »
Very nice. A minor optimization: in line 109 you can use rla instead of rl a, since you're not checking that zero flag anywhere.
Oh, oops, I copied that from my calc incorrectly, thanks! I'd just create two look-up tables: one for 0<n<1 and another for 1<n<255. Then, branch depending on the MSB of n. Actually, if you compute a reciprocal, you only need one table. Basically, your input really only has 8 significant bits; surely that can be used for an optimization. Your output domain is -5.6<n<5.6.
Edit: Use change-of-base rule: It's trivial to compute n-log-base-2, so just compute that then divide by the hardcoded log-base-2 of e value.
To your first point, you would only really need to look at the interval [1,2] which is all my code does. Essentially, it computes ln(x) by taking x=y2 n where y is on [1,2], then ln(y2 n) = ln(y)+ln(2 n)= ln(y)+n*ln(2) and I have ln(2) hardcoded. That being said, what you put in your edit makes a lot of sense. Shortly after this routine, I wrote a log 2 routine that is much faster, and because I would be dividing by a constant log 2(e) to change the base to natural log, the division routine could be optimised a bit, saving ~400 cycles. Also, the log 2 routine is much better because I can extend it to just about any size fixed-point (or floating point) numbers that I want. I'll edit my first post with that.
924
« on: May 30, 2013, 09:09:20 pm »
No, the registers aren't free since it will still be interpreted. The compiling simply precomputes things that can be, since that would save time. However, one of the features I forgot about was adding support for in-line assembly, and not just hex codes. For example, you might have a block that looks like:
Z80Asm
ld hl,plotSScreen
ld (hl),0
ld bc,767
ld de,plotSScreen+1
ldir
I do actually have a compiler started for this.
925
« on: May 23, 2013, 07:55:43 am »
For those that talk about time, think of Conway's Game of Life and us as the programmer. Of course it would be easy to just draw whatever it is that we want, but letting a simple ruleset play itself out is kind of fun. The neat part is that for us, a million iterations might take a long-ish time, but is not even a second in The Game's time.
926
« on: May 22, 2013, 08:08:13 pm »
We would have to mail them around the continents to get people to sign them, too (which could be fun).
927
« on: May 22, 2013, 07:47:05 pm »
I have been posting links for my IRL friends to check out , but I am pretty sure that would only bring in a few guests every so often, so it wouldn't account for 500 every day 
928
« on: May 22, 2013, 11:05:18 am »
I'd just like to congratulate everyone on getting to 5 pages without a flame war.
I think this prove we really can have a religious debate without going off the deep end.
Also, if this thread does start to develop into a flame war, could the offending posts be removed instead of locking the whole topic?
What's more is that we have done this even with a language barrier o.o Being on Omnimaga is awesome like that because you have to actively try to understand others, keeping in mind that there is a high chance that the other person probably comes from a different culture, different language, different religion, and different calculator and programming language preference >.>
929
« on: May 22, 2013, 08:37:29 am »
Ok. So then this can be said:
"How was the world created?"
"It wasn't. End of story."
No need for God then.
Note: I am still not saying "don't believe in God", you believe in anything you want. I just say that God is a possibility but only a possibility among others, maybe there is a God, maybe not, maybe there are two Gods, I don't know
That is right, and that is why I stated: This is not at all proof of a God-- this would be like saying, "if wizards existed, they could perform magic, so therefor magic must exist" without proving that wizards exist.
930
« on: May 22, 2013, 07:50:10 am »
Also, it seems that religious people tend to generate excuses to dismissively get rid of any challenges. For example
"How was God created?"
"He wasn't. End of story."
I actually find that to be a rather neat argument. Like harold said earlier, it is definitely interesting to think about something that is seemingly impossible (like something creating itself). At the least, it is a really creative exercise in logic, and at best, you might be shocked to learn that it is completely possible (this is how some scientific theories were stumbled upon, I believe). So what if something "created itself?" What limitations would it have? I would posit that it wouldn't be restricted. It could be something simple, unthinking, or it could be something all powerful. This is not at all proof of a God-- this would be like saying, "if wizards existed, they could perform magic, so therefor magic must exist" without proving that wizards exist. However, for somebody that believes in a god or gods, this might serve as a plausible explanation. For the rest, this is just a fun exercise
Pages: 1 ... 60 61 [62] 63 64 ... 317
|
Show Posts