Attached to this post is the full program, complete with unreadable cherry-flavoured source.

Warning: Source may contain too much cherry flavouring for some people to handle. Use responsibly.

EDIT: Low frame rate screenshot attached, also probably seen in Cemetech's archives, but forgot to upload to ticalc. Also, I hope running this program is understood well enough, since I also forgot to include that information in the ReadME.txt file. You can run this from either the homescreen or a shell (as an ION program). I'm unsure if the program description is up to date.

EDIT2: Whoops. Forgot to add that screenshot. Put it in now.

Thanks for telling me about this. Now I'm hooked >.<

My favorite method is to have the simulation quit after a large number of seconds, and time how long it takes to quit.

That was a great idea, thanks! I just remembered that there were online stopwatches, so I used one of those to time my program. I set my CA program to stop at 512 generations. The end result was about 38 seconds, which resolves to roughly 13.5 FPS @ 6MHz. My original calculation had it at around 16FPS, so that isn't too bad.

I did not time the other program, but I'm pretty sure that the older one ran much slower than that. Over all, I think this is a great success. Maybe a few minor adjustments may make this thing run ever so slightly faster, but I'm certain this is about as fast as it's going to get using this method of cell checking.

I suppose "tomorrow", I'll pull together the rest of the menu interface, add a few features additional features, and then upload this to ticalc.

Ce poste est traduit de l'anglais vers le français en utilisant "Google Translate".

Les informations concernant l'utilisation de l'extension de l'application PicArc Celtic III peut être trouvé dans le fichier de documentation. Une copie en anglais de qui est dans le codebox ci-dessous.

Une version stand-alone de PicArc peut être trouvé à l'URL ci-dessous. Les instructions sont également en anglais. S'il vous plaît trouver quelqu'un qui peut traduire les instructions pour vous. Je n'ai pas confiance la traduction assez pour donner des instructions appropriées.

Gardez à l'esprit que la base de données produite par la version autonome n'est pas compatible avec la base de données que Celtic III produit.

http://cadan.57o9.org/picarc5.zip

=================================================================== c009 ====
== CELTIC III PICARC EXTENDED COMMAND SET====================================
=========================================== uses the identity() token =======
=============================================================================
| Code/Name     | Command Description
-----------------------------------------------------------------------------
|00             | identity(0,"DATABASENAME",function,db_arg1,db_arg2)
|               |
|  DBQUERY1     | A nifty little function that allows many kinds of
|               | operations to take place with the PicArc database.
|               | The db_argument will vary depending on what you
|               | are going to do, but not by that much. Just read below.
|               |
|               | If function = ...
|               |
|               | 0 = Format this database. Just like anything that says
|               |     "FORMAT", you lose all preexisting data if that
|               |     file happens to already exist. This is not an undoable
|               |     action, so take care. If the file does not already
|               |     exist, it is created and then formatted. After you
|               |     use this command, you will be able to work around
|               |     with the file as a PicArc database. No arguments needed
|               |
|               | 1 = Append a picture file. db_arg1 will be the pic number
|               |     you want to refer to. For Pic1, argument will be
|               |     1, for Pic9, it'll be 9. For Pic0, it'll be 10. Keep
|               |     in mind that this command only appends Pic files. No
|               |     insertion is available, so be careful on the order of
|               |     Pic files you append.
|               |     
|               | 2 = Delete an entry. Starting at db_arg1 = 0, this command
|               |     removes the specified entry off of the database. This
|               |     command is NOT undoable, so exercise extreme caution.
|               |     
|               | 3 = Retrieves the number of entries in the database.
|               |
|               | 4 = Works just like function 1, except that this command
|               |     will attempt to compress the pic. It automatically
|               |     chooses the method of best compression so you'll always
|               |     get the smallest entry that the application is capable
|               |     of making, but using this command may be a little
|               |     slower than its counterpart. All the other commands
|               |     transparently decompresses compressed entries without
|               |     much of a speed loss.
|               |
|               | 5 = Copies the entry denoted by db_arg1 to the graph
|               |     buffer with the logic indicated by db_arg2.
|               |     0: REPLACE, no screen update.
|               |     1: AND,     no screen update.
|               |     2: OR,      no screen update.
|               |     3: XOR,     no screen update.
|               |     4: REPLACE, the screen is updated.
|               |     5: AND,     the screen is updated.
|               |     6: OR,      the screen is updated.
|               |     7: XOR,     the screen is updated.
|               |
|               | 6 = Copies an entry from the database as denoted by
|               |     db_arg1 (starting at zero) to a Pic file as denoted by
|               |     db_arg2. For example. to copy entry 6 of the database
|               |     "FOO" to Pic1, do the following:
|               |     identity(1,"FOO",6,6,1)
-----------------------------------------------------------------------------
|01             | identity(1,pic_number,function,[arg_1,arg_2...])
|               |
|  TOGGLEPIC    | This command takes Pic X (Pic0 = 10) and performs an action
|               | designated by a function number. If arg_1 = ...
|               |
|               | 0 = Copies Pic file to the graph buffer using logic method.
|               |     arg_1 specifies the Pic file
|               |     arg_2 specifies the logic code. The supported codes are
|               |
|               |     0: REPLACE, no screen update.
|               |     1: AND,     no screen update.
|               |     2: OR,      no screen update.
|               |     3: XOR,     no screen update.
|               |     4: REPLACE, the screen is updated.
|               |     5: AND,     the screen is updated.
|               |     6: OR,      the screen is updated.
|               |     7: XOR,     the screen is updated.
|               |
|               | 1 = Creates a new pic file using the contents of the
|               |     graph buffer. Any preexisting picture will be replaced.
|               | 2 = Swaps a pic file between archive and RAM. If it is now
|               |     in RAM, the output is 0, else it is some other number.
|               | 3 = Deletes a picture. This is not an undoable action,
|               |     so be cautious while using this function.
|               |
-----------------------------------------------------------------------------
|02             | identity(2,"GROUPFILENAME")
|               |
|  GETPICGROUP  | Outputs a list containing all the names of the pic files
|               | in the TI-OS group file. Each name is denoted by a number.
-----------------------------------------------------------------------------
|03             | identity(3,"GROUPFILENAME",pic_name_in_group)
|               |
|  EXTPICGROUP  | Copies a pic by name from the group and puts it into a pic
|               | file of its corresponding number. Any preexisting pic files
|               | are overwritten.
-----------------------------------------------------------------------------
|04             | identity(4,"BINSTR",xPos,yPos,Width,Height,StartX,EndX,
|               | SStartY,SEndY,Pic#,Logic,TileSize,Update_LCD,2ByteMode)
|  STRINGTILE   |
|               | See xLIB command "DrawTileMap" for information regarding
|               | the inputs. The only difference is that "Matrix_name" is
|               | replaced with "BINARYSTRING". For this, you supply a hex
|               | string converted to binary with the HEXTOBIN command.
|               | The Height and Width property of the command is used to
|               | provide a two-dimensional matrix feel to an inherently one-
|               | dimensional structure that is a string.
|               |
|               | If 2ByteMode is set to something other than 0, then the
|               | input string is considered words instead of bytes. This
|               | allows the user to use 4 hex ditgits (two bytes) per tile
|               | so up to 65536 different tiles can be accessed using this
|               | command.
|               |
|               | All other arguments function as they do with the xLIB
|               | command.
|               |
|               | As a developer, you should develop your tilemaps in hex
|               | and then use the HEXTOBIN command to convert it to the
|               | format required by this command. To edit this tilemap, you
|               | should use the EDIT1BYTE command while this tilemap is in
|               | its binary format.
|               |
|               | Note that any missing arguments will default to the value
|               | of zero (0) instead of 32 as in xLIB.
-----------------------------------------------------------------------------
|05             | identity(5,"HEXSTRING",x,y,w,h,logic,flip,update_lcd)
|               |
|  PUTSPRITE    | Works just like the xLIB command real(1,...) except that
|               | the Pic and the coordinates on that Pic file are not
|               | defined.
|               |
|               | Instead, a string consisting of hex digits is used to
|               | define the sprite as inline data. For example, if you
|               | wanted to draw a black 8*8 block at the top-left corner of
|               | the screen with XOR logic and drawn immediately...
|               |
|               | identity(5,"FFFFFFFFFFFFFFFF",0,0,1,8,3,0,1)
|               |
|               | Useful for those that want to display sprites without the
|               | use of bulky image files.
|               |
|               | For large sprites, each byte goes LEFT first, then DOWN,
|               | so specifying "80FF0180000180000180FF01" would relate to
|               | such a perfect box 3 bytes wide and 4 pixels down.
|               |
|               |
|               |
|               |
|               |
|               |
|               |
|               | Note that any missing arguments will default to the value
|               | of zero (0) instead of 32 as in xLIB.
-----------------------------------------------------------------------------
|06             | identity(6,shift_number_of_times,direction,screen_update)
|               |
|  SHIFTSCREEN  | Shifts the image on the graphbuffer a number of times in
|               | a direction indicated below.
|               |
|               |       left : 1
|               |      right : 2
|               |         up : 4
|               |    up-left : 5
|               |   up-right : 6
|               |       down : 8
|               |  down-left : 9
|               | down-right : 10
|               |
|               | If screen_update is zero, the screen will not update.
|               | Otherwise, it will update.
-----------------------------------------------------------------------------
|07             | identity(7,x_left,y_top,x_right,y_bottom,display_method)
|               |
|  DRAWBOX      | Draws a box which corners are (x_left,Y_top) and
|               | (x_right,y_bottom) using a specified display method.
|               |
|               | Since this display method code is not complete, let's say
|               | that it is xLIB-compatible with the drawshape command,
|               | minus three. Add 128 to this number and the screen will
|               | also be updated.
-----------------------------------------------------------------------------
|08             | identity(8,"HEXSTRING",Right,Down,LOGIC,UpdateLCD)
|               |
|  FILLMAP      | A command that fills the screen with the same 8 x 8 tiles
|               | as defined by 16 hex digits. Along with the right and
|               | down shift arguments, this command makes scrolling
|               | backgrounds far easier.
|               |
|               | The hexstring, as said before, is 16 digits long, 8 pairs
|               | which makes up an 8 by 8 pixel tile.
|               |
|               | The right and down arguments determine how many pixels
|               | the filled map should be shifted. You can either choose
|               | not to shift or shift in either direction up to 8 pixels.
|               | Since the routine does mod 8, you can actually have these
|               | numbers increment and decrement bounded by -65565 to 65535
|               | so you should not actually have to test for bounds save for
|               | those already mentioned.
|               |
|               | LOGIC applies a method used to write the tiles to the
|               | buffer. 0=overwrite ; 1=AND ; 2=OR ; 3=XOR
|               |
|               | If UpdateLCD is anything other than zero, the screen is
|               | updated with whatever was just written to the buffer.
|               |
|               | Additional note: The bounds are actually -99999 and 99999
|               | and it'll still function properly due to how the custom
|               | float to integer routine works. This "bug" is not likely
|               | to be fixed. It's not hurting anything. It's safe. No one
|               | is gonna wait at a menu for as long as it takes to cycle
|               | through the routine *that* many times.
-----------------------------------------------------------------------------
|09             | identity(9,x,y,w,h,Dir,Type,Repeat,LCD_update)
|               | ***NOT FULLY IMPLEMENTED YET***
|  BOXSHIFT     | This command shifts or rotates within a box-shaped area on
|               | the screen (and may be the whole screen if you want).
|               |
|               | x = top-left corner x, 0 thru 11. (each 8 pixels is a byte)
|               | y = top-left corner y, 0 thru 63.
|               | w = width of box object, 1 thru 12. Specifies byte widths.
|               | h = height of box object, 1 thru 64
|               |
|               | Dir : Each will have a basic direction followed by
|               |       what you must add to it in order to perform
|               |       a different type of shift.
|               |       left = 1
|               |      right = 2
|               |         up = 4
|               |    up-left = 5
|               |   up-right = 6
|               |       down = 8
|               |  down-left = 9
|               | down-right = 10
|               |
|               | Type: Determines what type of shifting is to take place
|               |       0 = Keep bit being shifted in
|               |       1 = Shift in a black bit (for black backgrounds)
|               |       2 = Shift in a white bit (for white backgrounds)
|               |       3 = Let bit that shifts out reappar on other side
|               |           (for scrolling backgrounds)
|               |
|               | Repeat: A number that repeats the shift operation as
|               |         many times as specified. Cannot be zero.
|               |
|               | LCD_update: If it is a number other than zero, the screen
|               |             is updated with the results.
|               |
|               | Notes: The routine does not perform clipping. All
|               |        coordinates and dimensions must remain onscreen.
|               |
|               | Tips: If you don't update the LCD, this command is real
|               |       useful for dynamically editing tilemaps by loading
|               |       them to the buffer, using this command to edit them,
|               |       then store them back to the pic file, all without the
|               |       buffer ever being updated. The procedure is fast
|               |       enough to be dismissed as a slight slowdown due to
|               |       the BASIC parser.
-----------------------------------------------------------------------------
|10             | identity(10,flag,[x,y],"TEXT")
|               |
|  DRAWTEXT     | Draws text to the graph screen with the coordinates x,y
|               | using the small font. The screen is NOT updated. If you
|               | wanted to updated it, you should've used the Text() command
|               | instead.
|               |
|               | If you omit the x,y coords, the text is drawn to the last
|               | coordinate the previous DRAWTEXT command ended up. Does not
|               | line-wrap. It's your duty to do that yourself.
|               |
|               | If you don't want the text to be modified in any way, set
|               | flag to zero. If you want to modify, you should do addition
|               | to the value using these numbers:
|               |
|               | +1 = Draw using large font.
|               | +2 = Erase 1 row of pixels below the small font base
|               | +4 = Invert text
|               | +8 = Hex string is used in place of text to use font map.
|               |      If you know the character's hex value, you can use it.
|               |      Advantage: Get chars you can't access any other way.
|               | +16= Update screen anyway. Just a throwback.
|               |
|               | Example: I want to use the large font AND invert text
|               |          at x=4 and y=8 using "THIS IS TEXT" as text.
|               | identity(10,0+1+4,4,8,"THIS IS TEXT")
|               | - or -
|               | identity(10,5,4,8,"THIS IS TEXT")
|               | [ note that the flags have been condensed ]
|               |
-----------------------------------------------------------------------------


The image that I have posted is not the version that I am proposing. What is posted is my preexisting version, dating back to 2006-2007. It runs at a nice 8.73 FPS @ 6MHz according to Wabbitemu (fastcopy doesn't like it at 15MHz).

Now... what I am trying to say is that I don't think 8.73 FPS is fast enough. Me, Runer112, and (I think) ZippyDee was chatting late last night. Runer112 was trying to help ZippyDee with something about a flood fill algorithm and the manner in which he was doing it reminded me about my old 2D cellular automata program, so at one point, I innocently showed the main code to this program to Runer112 on IRC and asked him to optimize it. He basically went "wtf?" at my code and wrote it off as unoptimizable, so then we sort of went around talking about how it works, and trying to explain to him the insane method I was using to do the job. And then, at some point he suggested something that I realized I was already doing in E:SoR. Why not do 2D-CA on a vertically-aligned buffer? Yup. So now that's what I'm working on. Vertically-aligned goodness.

Now, this new version is not going to sport that flashy menu system, more or less because version 1.3 had a menu bug that would cause the calc to crash almost randomly. I never really figured out what was causing the problem. But try it out at your own risk. I'm also attaching that package. Because I'm not going with something fancy, I figured I'd go with something more intuitive instead. Like image thumbnails of what you're trying to save or load against what was already done in the 2D play field. Like the original, you'll be able to change the rulesets right from underneath an already in-progress field. That is, it'll pause when you try to quit and continue from where you left off (if you don't exit the program, that is).

So, yeah. I'm taking a small break from E:SoR (or rather, hop back and forth between the two) to work on this small, but satisfying project.

Also, I plan on having default images built in so you can select them if you don't have the pic files of what you want.

EDIT: FWIW, by "2D Cellular Automata", I'm referring to 2 two-state system in a Moore neighborhood, which is what Conway's Game of Life is run on.

I'm okay about getting OmnomIRC in on #fishtankcity. Moar people to discuss stuff especially during the busier times on #omnimaga.

So... I suppose you should talk to His Lobsteriness about it now, since it pretty much is his chan.

Yes! Thank you!!
I've been wanting some sprites from Escheron: Shadow over Ragnoth!
is that all the tiles in the game? aren't there more?

Those are all the tiles that are rendered as part of the tilemap routine. Character sprites, on the other hand, are rendered by a nonexistant sprite routine (You try writing a masked 4-level grayscale sprite routine that operates on an grayscale-interlaced vertically-aligned buffer. calc84maniac refused to do it for me, though I dunno if it's because he wants me to feel the pain or if he just doesn't want to).

I am not willing to share the entire spritesheet at this time, if only because that part hasn't been finalized. If you absolutely need to have some sort of example, I suggest looking through some of the topics in the E:SoR subforum. All the good topics have related images in the first page that you can use as a reference. Except the really long ones. In that case, I might make the suggestion to use the "View attachments" link which takes the form of a paperclip next to the topic title.

The stuff found in those threads contain preliminary work, which may or may not appear as they are in the final revision of E:SoR.