The starting idea was to roll a ball along a path which scrolls downward, so I wrote code to generate then animate the path. I'd originally wanted to draw pairs of triangles for each "square" so I could transform those edges later on when I added the 3D perspective. The result was freakishly slow, so I instead wrote an assembler routine to try to draw what is basically a trapezoid (given that's basically what each tile is when rotated along the Z-axis). I was unable to get it to work right, so I went with coding a larger assembly routine to draw the entire board at once. I still hadn't worked out what needed to be done to make perspectives work but I had enough to draw something.
The path
I now needed to make a ball that looked like the rolling thing from the original game. Except, my "artistic skills" was woefully lacking in that department, so I took a detour to my fun Python setup to see if I could render frames for a rolling ball sprite that way. Turns out, I knew too little about 3D... anything... so I had to break out some textbooks and stare at wikipedia for days until I figured out something that would let me rotate a sphere in exactly the way I wanted it to.
Haha no.
What is this i dont even
what the flying...
Finally, something usable
With a bit of little cleanup and paint.net magic...
Perspective. This is what caused me nearly endless grief. The lookup table generator was at the beginning slower than the process it took to compile the program. The assembler routine responsible for drawing the board needed to be rewritten several times. I also started using Git to version the project since I didn't want to mess up and having to scrap everything (yet again).
Behold, a failure
That doesn't look right
Starting to look reasonable
A few more tweaks to the assembler routine made the path solid. Wrote another assembler routine to fill in the background faster, with a custom palette to give it that gradient. Changed how jumping worked to give it a nonlinear arc and to increase the size of the ball as it moves upwards to simulate additional perspective.
It's almost there
From there, I added: * Explosion animation on quitting * Falling animation if you miss the path * Help * High score retention
I'd also reduced the frame count of the explosion and reduced the color depth of the title graphic because 20KB for a game this simple just isn't acceptable. I also modified the perspective a bit more to give it a more faraway look, tweaked speeds a bit once geekboy1011 (final tester) mentioned about how ridiculous it was on hardware, and made the random path generator less cruel about unfair gaps.
Would an extra 4KB have been worth keeping the high quality title graphic?
And here we are at release 0.1. Check the project out on GitHub
Kinda sorta crosspost from Cemetech, except a summary in both text and screenshot form.
So Geekboy1011 convinced me to try the rebuild of Escheron: Twilight over Ragnoth in Python so I can get the game out faster, and on other platforms. I justified this as an opportunity to finally have a low(er) effort method of coding cutscene/scenario data then backporting it to the calculator. Who really knows what's going on?
So far, I've got a simple title screen, some maps, NPCs, some menus, and some scripts (which allows use of vehicles at the moment but will drive scenarios as well).
Spoiler For Reason for first screenshot cutting off:
TODO: Shops, adding and linking remaining maps, sticking in preexisting NPCs, battle system, title sequence, and then everything else that didn't make it into the calc version before I stopped working on it.
NOTE: Once I feel that the code isn't going to spontaneously mutate into an eldritch abomination (which tends to happen with distressing regularity), I'll move the git repo from gitlab to github. Or something to make it public and easily findable.
This was largely inspired/copied-wherever-appropriate from this older project where I tried to get this video or one of its variants to play on a calculator in a somewhat efficient manner.
Two days, and many tears over lost notes because apparently if you don't test your backups, you ain't got a backup, and a bit of magic with Python and varying libraries, I recreated what I had except it has a much neater process of making a video that doesn't require any intermediate user interaction or arcane commnad-line invocations.
Spoiler For That Python Script:
Pasting my Python script here since I really don't want to lose it.
af_called = 0 buffers = 0 max_frames = 23 cur_frame = 0 framebuf = [] compressed_arrays = [] total_len = 0 #----------------------------------------------------------------------------- def readFile(file): a = [] f = open(file,'rb') b = f.read(1) while b!=b'': a.append(ord(b)) b = f.read(1) f.close() return a
def writeFile(file,a): f = open(file,'wb+') f.write(bytearray(a)) f.close()
def addframe(framedata=None): global max_frames,cur_frame,framebuf,af_called,compressed_arrays,buffers,total_len af_called += 1 if framedata: framedata = ''.join([chr(~ord(c)&0xFF) for c in framedata]) app.updateframe(framedata) framebuf.extend(framedata) cur_frame += 1 if cur_frame >= max_frames: framedata = None # If framedata was None either on init or set during running, flush buffer. if not framedata and framebuf: tfn = np(cwd+'/bin/tempimg') tfnc = np(cwd+'/bin/tempimgc') writeFile(tfn,framebuf) subprocess.call([np(cwd+'/tools/apack.exe'),tfn,tfnc]) outarray = readFile(tfnc) compressed_arrays.append([buffers,len(outarray),outarray]) total_len += len(outarray) buffers += 1 print "Buffer "+str(buffers)+" flushed at call number "+str(af_called) framebuf = [] cur_frame = 0
def dumptofile(fn,arrobj): filename = np(cwd+'/dat/'+fn) with open(filename,'w') as f: curchar = 0 s = '' for b in arrobj[2]: if curchar == 0: s = '.db ' s = s+'$%02X' % b if curchar == 16: f.write(s+"\n") s = '' curchar = 0 else: s = s+',' curchar += 1 if s: f.write(s[:len(s)-1]+'\n')
def usage(): print '''Biscuits Video Converter Usage:\n python convert.py <input_video_file.ext>\n''' return #----------------------------------------------------------------------------- '''FFMPEG NOTES: -ss timestamp : Grab video starting at this timestamp -c copy : -c for codec. 'copy' keyword to ensure no reencoding -t timestamp : Duration of encoding -vf filtergraph : Alias for -filter:v (filter for video stream) using the crap in 'filtergraph'.
with open(np(cwd+'/dat/filelist.z80'),'w') as flister: flister.write('#define getCurpage(x) x>>16\n') for i in compressed_arrays: tfn = 'I'+str(i[0]).zfill(3)+'.z80' flister.write('.dw '+tfn+' \\.db getCurpage('+tfn+')\n')
with open(np(cwd+'/dat/numfiles.inc'),'w') as nfil: nfil.write("NUMBER_OF_FILES .EQU "+str(len(compressed_arrays))) #Sort by length of outarray, descending compressed_arrays = sorted(compressed_arrays,key=lambda i:i[1],reverse=True)
slack = -1 curfile = 0 curpage = 0 tslack = 0 maxslack = 16383 with open(np(cwd+'/dat/myinc.z80'),'w') as finc: while len(compressed_arrays)>0: curpage += 1 finc.write('defpage('+str(curpage)+') ;Prev page slack:'+str(slack)+'\n') slack = maxslack i=0 while i<len(compressed_arrays): if compressed_arrays[i][1]>slack: i+=1 else: a = compressed_arrays.pop(i) tfn = 'I'+str(a[0]).zfill(3)+'.z80' slack -= a[1] dumptofile(tfn,a) finc.write(tfn+': #include "dat/'+tfn+'" ;File length: '+str(a[1])+'\n') tslack += slack print "Page "+str(curpage).zfill(3)+" with slack "+str(slack).zfill(5)+" emitted."
print "Compressed "+str(768*len(flist))+" bytes to "+str(total_len)+' with slack bytes '+str(tslack) print ":::: Completed."
I'm also total Undertale trash and I wanted to do something that involved it. So I chose one particular video and ran the converter. I think it turned out pretty well. Check it out here:
Attached to the post is the empty source needed to build and the app that resulted from the build.
At around the end of October, Geekboy1011 pulled together E:ToR into a closed alpha and started accepting applications for that. During that period I decided to take a small break from that project but I didn't want to announce that anywhere for fear of pitchforks, torches, and rolled-up Sunday newspapers. The signup period lasted roughly a week, so I decided to try for a project that would take about that much time. I thought about Geekboy1001's rendition of Scognito's Scogger game called ScoggerT and figured it would be easy enough to port to the CSE. I already had a level editor (which was made for Geekboy1011) and the important bits of NaCaniS to work with.
The rest of the dev team (Geekboy1011 and Zera) was pretty much waiting on the signup period to end, so we decided to tackle this project in the meantime. The end result?
That's what I call it but the title screen says it's Scogger+. I didn't bother correcting Zera (the project's graphics designer) since I didn't really want to rearrange things again.
This game features all original 100 levels, formatted to fit in the game's 8x6 grid (originally 8x8). Thankfully, all the levels were editable in such a way that it changed nothing about how each level was solved. The editor that I wrote and used (which is included with the game) looks like this: You'll need AutoHotkey L installed to run the editor since it's written in AHK.
The game also features 50 extra levels made by Zera in Scogger+ mode, which includes two additional tile types to enhance the gameplay.
There's a bit of a load time when the game starts, but as far as my testers have been able to tell me, it plays well and plays beautifully. Although Wabbitemu doesn't do a perfect job emulating the CSE's half-res mode, I was able to grab this animated screenie using an external screenshot tool:
The game also provides basic amenities such as recording your progress, marking it (red level numbers are levels not completed, green are those that are), and being able to delete it.
-------- For those of you who are interested, the download contains everything you need to rebuild the project, aside from Python 2.7, PIL, and a WinXP+ environment (which are mentioned in the readme). The level editor is included, but you'll need to jump through a few hoops and hurdles to actually play them since Scogger CSE does not support external level packs. That's also detailed in the readme.
Instructions for using the level editor itself is not included, though pushing F1 with the window in focus can help.
The source is openly available. I am not responsible for any adverse health effects caused by reading such awful code. You have been warned.
Well... Aegis-Rin didn't pan out. Got bogged down by the details and tbh, was created to be a bit too general without any real knowledge on automating the build procedures that would be necessary to make using the system easier. So instead we started over again. With further in-depth understanding of Brass' macro system, we've got the whole thing eaiser to code and compile.
Oh. And we have an actual plan. A real. Plan. On a piece of paper. Showing what needs to be happening.
Update * Most magic animations are now complete. * Additional content added to Underdeep. It's now its own story arc. * User and script-adjustable typewriter effect. * Other things.
Demonstration of typewriter effect and some of the magic. We have more down but I don't want to spoil too much.
Notes Battle animations would've/should've been done sooner, but some of these things take a while to animate in a way that satisfies the whole team. There's still a few things left to animate, but it won't be long now before it's all done. After that and a few visual/bug fixes we get to do...
Cutscenes! Geekboy1011 is hard at work at the moment putting all the cutscenes together between the time you choose the "New Game" option to the time you gain control of your character for the first time. When I finish the battle animations and find myself satisfied with the system as a whole, I'm going to be jumping in somewhere in the middle to get the game's story stitched together. Zera/Escheron mentioned that the cutscenes he's been working on as of late are encroaching into Golden Sun-length territory. This could be a good thing.
There's also now no way in hell we'll be able to fit this game onto a normal TI-83 Plus without modifications. There's just too much content we want to add and compression we have isn't doing a good enough job. I mean, it's doing a fantastic job so far, but we just have so much to put in. I'm entertaining the idea of creating a miniature OS that contains just the basic calc functions so I can reasonably distribute this game as an OS update instead of an app. Something that would, on the surface, look just like the TI-OS until you try digging into the menus and realize they're all empty. While I do want people to play this game, I also want their calculator be usable as ... a calculator. This is planned after a release for the TI-83+SE / 84+(SE) monochrome calcs.
The Underdeep will have static floors interspersed between randomly generated floors which will also be randomly, but not repeatably, chosen where fun events can trigger and backstory can be told. Yes. The Underdeep now has its own story to it which further enriches the world of Escheron. I'm not privy to all the details for the same reason I'm not looking too deeply into the scripts for the game: I want to be able to enjoy playing this thing without too many spoilers once we finish coding the game.
TODO * Remaining skill/magic animations * Cutscenes * Specialized transitions * Update the Underdeep mapgen scripts
The game is now fully scripted. All of the character dialogs and cutscenes are written, but their actual incorporation into the project make take some time, since working with the cutscene engine is a nightmare in itself. (And luckily, that task falls upon Iambian and Geekboy1011 instead of me, since I'm not as technically oriented with the systems)
Planned builds
83+: on hold Project got to large.
84+: Current supported platform.
84+CSE: A compatability layer is included. Support for this platform will be limited.
84+CE: Never due to needing to rewrite everything for it to function on this platform.
Originally a Cemetech contest entry (no. 13), I expanded upon this entry after the due date to have the project more closely match the vision I had for it on project inception. Since it was a Cemetech thing, they got it first, but here do I release the (most likely) final version. Attached to this post is NaCaNiS version 0.4.
The program is a bit hefty, tho. Weighing in at about 20KB (~13KB of which is story material), you'll need to make sure much of your RAM is cleared before running. You'll need Doors CSE or a shell that can run nostub ASM programs to get prgmNACANIS to run.
If you want a simple cat game with no story mode, send NCNS003.8xp to your calculator instead. That's only 7-8KB and will run on the homescreen as a nostub ASM program.
This is a TI-84 Plus CSE game. It will not run on any other calculator.
For a week or two, I've had this thought about making another Z80 assembly tutorial. At the moment, the best tutorial out there is Asm In 28 Days, but I've heard complaints regarding its usability for new people for actual learning material. Sure, it makes a wonderful reference but the one thing I've found is that it doesn't have workable, testable examples and things that one can be done to help reinforce learning. I don't know about most of the other people out there, but I learn best by doing, and the tutorial I want to make will cater to that sort of crowd.
I started writing a sort of road map concerning the topics that should be discussed, and in what order to present them in. I figured that if I want to actually write a tutorial, I'd best have an outline first before announcing anything since an announcement in and of itself isn't all that helpful in getting this idea off the ground.
This is what I have after a bit of thinking. Comments and suggestions appreciated.
Z80 Assembly Tutorial For the TI-83 Plus (SE) Centered around creating a simple game, then making it run faster. Better. Each section should have DIY tasks to help them understand a concept better. Subsections explaining actual instructions will be indexed in a different color.
* Introduction What ASM is, isn't, what it takes to learn, and tutorial methodology.
* Development Environment - Assemblers and getting your first binary (.8xp) assembled. - Link software if you have actual hardware - Emulators and how to use them.
* Numbers, Variables, and Memory - A forward. All these topics will involve the use of the LD instruction and its many variations. - Numbers - Discussion on decimal, hexadecimal, and binary and why to use them. - A short note on octal and that it was historically used. - Variables - Discussion of registers and their short term scope - A short note on other special purpose registers and their functions - Short discussion about the stack and its longer but still short term scope - Discussion of SafeRAM and their scope in-program. - Discussion of files and their persistence after a program ends. - Memory - What memory is, and the different types on the calculator - Memory maps and address range - A listing of various stretches of safeRAM on the calculator - Memory access is just another number. Talk about indirection here. - Hardware - Very short explanation that additional hardware such as keyboard, memory map ports or LCD are accessed via IN/OUT instructions. Each has their method of access, and is only briefly mentioned here because memory was discussed.
* System Calls - A short section on what a bcall is. - Locations and places of references for said system calls.
* Something Useful - Messing Around With Text ( Should showcase all manners of LD instructions and use here ) - Introducing useful romcalls for messing with the homescreen. - A reminder that romcalls can and will mess around with the contents of registers and that registers are for SHORT TERM STORAGE. - Displaying a string. - Introduce the CALL/RET instructions for subroutines - Displaying one character at a time - Introduce math instructions (ADD/SUB) (INC/DEC) - Displaying numbers from registers
* Key input - Introduce program control flow via CP/JP - Introduce system calls for getting key input, link to reference table - Have the user do stuff with keypresses to make the program display different things - Implement text "sprite" onscreen and move it around. - Introduce and explain z80 FLAGS - Tie in this knowledge with math instructions - Using that knowledge, implement movement boundary checking
* The Graph Screen and Graph Buffer - Introduction to graph buffer and the separation between that and the LCD - Displaying text on the graph buffer. - Re-implement text sprite on graph buffer - Using system calls to draw lines and boxes onscreen - Introduction to sprites and the many methods of drawing them to screen - Will use ION sprite routine as basis. Its operation will not be explained yet. - A note that this topic will be re-visited later on to support clipping
* The Stack - Introduction to what the stack is and what it's used for - Introduction to PUSH/POP - Explanation of push/pop procedures. - Upgrade previous program with it. - Explanation of CALL/RET and how it messes with the stack - Explanation of EX (SP),HL and its use - Short explanation of direct stack manipulation - Note on how this is generally used to create an exit-from-anywhere point. - Caveats about using SP in a manner other than for call/variable stack purposes - Link forward to interrupts section if student really wants to abuse SP
* Arrays and Jump Tables - Arrays and what they are (Now would be a great time to discuss indirection - How to read/write to/from them - Methods of managing them (if at all) - Great place to introduce block copy instructions (LDI[R]/LDD[R]) - At this point, we can create a graphscreen game based on avoiding other moving objects - Jump tables - What they're for - Jump tables filled with 2-byte addresses - Jump tables filled with 1-byte offsets
* Bitmasking and Bit Math - Introduction to system flags and BIT/SET/RES instructions - Messing around with inverting text and those various flags. - While we're at it, accelerate text drawing by making vputs routines buffer-only - Introduction to the zillions of rotate/shift instructions available on the z80 - Might as well introduce direct keyboard reading now - Shifting and rotating results out to carry seems like a great method to use. - Upgrade the game with this. - Introduction to AND/OR/XOR instructions - Methods of bitpacking so varibles take up less space - Setting, resetting, or testing multiple flags at the same time - Bitmasking and examining how ION's sprite routine works
* Interrupts - Explanation of what interrupts are and how they may be useful - Enable, disable, and create and clean up after interrupts - Hardware differences that influence this on the SE's and 84's
* LCD and Direct Access - Details of the screen itself and manner of access via ports including delays - Reference of commands and things you can do - Introduction to ION's fastcopy routine - Introduction to grayscale. How to abuse interrupts and slowness of LCD to achieve
* Accessing Variables Outside Your Program - List of what a file is and the various filetypes on the calc - Details of each file type and their use - Romcalls used to check for, access, create and delete variables - With this, perhaps we can create an external high score file? - How to resize variables if you weren't sure how large they ought to be on create - Explanation of what the VAT is and how to traverse it - Explanation of how to access archived variables without unarchiving them first
* Use of TI's Floating Point Structures - An overview of what floating point numbers are, and a quick note on fixed-point - None of our examples will use them, but this topic is covered for completeness. Perhaps you'll get an idea that requires decimal precision and this works. That circular version of the worm game comes to mind. - Details of TI's floating point format - Available romcalls for moving floats and float-sized data. - Available romcalls for manipulating the Floating Point Stack (FPS) - Available romcalls for mathematical purposes
* Fixed Point Mathematics and Mult/Div routines - What fixed point math is and why it may be better to use it - Outline of multiplication - Naive method - Faster multiplication method and why it works - Outline of division - Naive method - How to use fixed point math ideas to multiply by reciprocal instead. - Division is slow and awkward. This is a way to avoid it - Faster division algorithms and why they work. - Oh gawd. I am NOT looking forward to this section.
* Creating Flash Applications - What Flash Applications (FlashAPPs) are and why to use them - Changes to the dev environment to support FlashAPPs - Differences that must be observed (e.x. how to exit flashapps, no SMC, etc.) - Multipage FlashAPPs - Doing it TI's way, through the use of an in-app bcall table. - Doing it our way, through the use of a pagechange stub. - Might as well introduce how to mess around with memory mappings here. - Also discuss cross-page access
THIS IS WHAT I HAVE SO FAR. CHERRIES FOR EVERYONE.
Has anyone been able to disassemble the bootcode and make some text document on it? For the Silver Edition, most specifically? Or both?
I'm just wondering, because I'm ending up writing it all down on a piece of paper. (That's time consuming, but I guess I need some way to pass the time at school)
Downloaded and converted a copy of Rick Astley's popular music video for the song "Never Gonna Give You Up". The screenshot gives the basic gist of what you'll be looking at, the .8xk download is the first 5000 (of 6,392) frames (roughly 2 3/4 minutes long)
On-calc filesize is 966,656 bytes (944KB). SPASM refuses to compile the entire video (it crashes if attempted).
First 5000 frames because it was a nice, easy number to pick that would still compile. The original video would've spanned 72 pages, and SPASM crashes on attempting to compile that.
Note that there is no real audio, but if you try anyway, you'll end up with a low pitched hum (since the audio driver is never disabled)
Anyone here have a copy of apack? It's some sort of compression scheme and someone ported it to the 83+, with a PC command line util to do the compression.
I lost my copy and Google is being very unhelpful. The only references that seem to get me anywhere lead me to dead links.
EDIT: Nevermind. Didn't search hard enough. A copy was on one of the CD's that I had lying around
This was a quick attempt to see what I can do with the stuff I've already made. This attempt recycled both sides of the Athena Installer/Packager project to process the video via modified pucrunch. Much of the time spent was trying to get the youtube video into a format I could work with (ffmpeg and irfanview were used).
Since Athena was re-used, the executable is in the form of a main executable followed by loads of files. Here's some numbers:
Total number of frames: 6585 Memory used if not compressed: 4.8 MB (5057280 bytes plus headers for required number of files) Memory after passing it through Athena: 1.03MB (1088847 bytes including headers for 81 .8xp files) Executable size: 944 bytes (including .8xp header) New lines of z80 code: ~100 New lines of Java code: Less than 50 Average framerate at 15MHz: 25FPS
If you've read the last part, you'll know that the decompressor ran a bit too slow for real-time video playback. This *can* be fixed and made better, but the point of this was to see what I could do in a single day. I do plan on working on this a bit more.
Known problems: Playback is too slow, unknown corruption in the encoding (can't find)
Warn: Attachment below is a 3.5MB video of the results so far.
Over the past couple of weeks, I've been working on a four channel interrupt-based music player for use in assembly games. This program is for 15MHz+ calculators, so no, it won't work on normal TI-83+. Today, I'm proud to report that I've gotten more than just a frequency sweep test written. Today, I've got actual music to play.
For this test, I embedded the source (almost verbatim) of the track "Same One (Bellon)" found with QuadPlayer, and wrote a small routine that feeds that information almost verbatim into the sound driver. After tweaking the frequency delays of the audio interrupt and messing with the tracker timing, I ended up with this: https://soundcloud.com/iambian-zenith/audiotest2/s-q7HJz
(Note: The music is much cleaner on hardware. And when the computer trying to record this isn't struggling)
More work needs to be done with the actual timing or file interpretation (or perhaps the source is at fault? I dunno.) and there does seem to be distortion in the sound at higher frequencies. For the sound linked above, the crystal timer for the sound driver is set at CPU (15MHz) / 8 with a delay count of 30 (which resolves to about 62.5KHz), while the timer for the music tracker was ... well.... guessed and tested until I found that it played it at a rate "close enough" to how QuadPlayer played it.
At the mentioned rate above, I ran further tests to see how much of the CPU is actually taken by the audio interrupt. Using Wabbitemu, I got ~76.5% used, while on my TI-84+SE, I got ~74.8%. During tonight's HCWP, I'd like to distribute this test program to see what numbers other people are getting. I'm especially curious to see if the timings vary a bit more on TI-83+SE hardware.
Another note: Since this an audio-only program, there isn't much in the way of screenshots, unless you like watching a blank screen for the current test, or a bunch of rapidly-changing numbers for the prior test.
Show Posts
