Could you use one buffer for the rectangles and just draw a line at the bottom of each rectangle every frame and not erase the previous one? All you would have to do then is draw 16-24ish horizontal lines each frame. (and do the bit of trig to figure out where it should be) You would need another buffer for the screen and another for double buffering but drawing the colored background then copying over the rectangles then drawing the ball should be very fast. All that probably isn't needed because it looks really smooth as it is. It was fun to think about though
I double buffer the whole thing to help prevent artifacting, so introducing a third buffer isn't something I want to do due to soft memory constraints. Were I to try it anyway, merging two screen-sized buffers is a very slow process even after somewhat minimal processing is done on each. The program is already fast enough as it is (pushing close to the maximum allowed framerate) since I'm doing some trickery to accelerate the rendering, such as push slides to render the background and drawing the lines via lookup table.
You raise a good point about the lines thing now that I think about it. If I kept track of each of the two buffers, I could skip out on a lot of redraw costs by keeping and redrawing the stuff behind the ball sprite in each of the two frames to allow movement, do some tricks with the score to redraw the background behind that, and take a differential between the current index and previous index in the LUT to partially redraw the background behind the tiles. This way I could do away with drawing the background altogether (apart from init) and only need to partially redraw the field at the cost of added complexity with the ball.
I'm just a little iffy on the idea of changing the line renderer, though, since that would increase the complexity of something that's already at the edge of what I'm comfortable with. But it would let the program maintain a solid 60fps. Something to think about for v0.2
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.
I kinda sorta maybe fell in love with C and developing on the CE so I'm thinking about just dropping the b/w version and working on a color edition. It's just much easier trying to code something that way. If anyone else wants to pick up the rebuild from where I left off, I'll be happy to provide support, but until I find my love for z80 and overly-overengineered script systems again, I'm not sure I'll pick this up again.
It would be nice programming on a device where I don't have to worry so much about memory or paging. Or making up languages to keep size down.
Good to see that this is finally released! I'll definitely play this when I get a chance! And it also means I get to have a whole 'nother year to work on Escheron since I know what's winning the 2017 POTY award...
I knew I had to make this sort of post eventually. *sigh*. I know someone's going to give me grief for this.
Update: * Complete rewrite of the Escheron: Twilight over Ragnoth project -- Text hive objects apart from static elements now build inline with tilemaps to help fill some page gaps -- Menu and cutscene systems fully redone and consolidated. It's almost like a VM now -- Map/sprite systems consolidated -- Hotspots mostly rewritten and optimized -- Sprite interactions optimized and dead/useless code removed -- Some simplistic cutscenes have been added back in -- Battle input menus and enemy scripts added back in * Changes to the toolchain -- Aforementioned text hive objects now build from an editor project file. Editor is also included -- Consolidated all build scripts so asset building takes ~80% less time on Windows (we have nothing for Linux yet (again)) -- Project data optimized to nearly double main build speed. Who knew ".org" was an expensive operation? -- Added far more points in the source to identify how much space each module takes up
No screenshots. Sorry. Much work remains to be done before I can announce my total failure to make any progress.
Notes: Two months and four days. From the initial commit to the new repository to the date of this post, that's how long it's been and that's how long I've been working on the rewrite for Escheron. As for the reason for the rewrite? Long story short, there were too many memory issues and too many things that were either unmovable or I couldn't tell which page any of the data was on.
This all started out when I wanted to integrate ECE2-generated text hive objects and then it all snowballed when I also wanted to change out the text system to something that was Turing-complete (with a minimal register/instruction set). I didn't realize at the time that more than half of the whole game depended on the text system in some form or fashion and at that point I decided I might as well rewrite it all.
I'm still going to salvage as much of the code as I reasonably can because there's just some things I won't rewrite no matter what. Battle magic script system/data, I'm looking at you! Those animations, while fun to make, were also absolute hell to get right.
If you want to track the progress of this rebuild, I do my best to make daily commits to this repository, even if it's "omg everything broke sadfaic".
TODO: * Escheron: -- Put vehicular travel back in -- Re-finish battle system -- Put back all the maps -- Put previously coded scripts back in... -- ...including the Underdeep mapgen script -- Put back that thing I refuse to mention because superstitions. Or not. It's not important -- Manually code in the first few cutscenes and get people to test the game up to that point -- Somehow get all the other cutscenes and events coded in
Escheron Cutscene Editor GUI does look great but just out of curiosity how old is the windows version?
However old Win7 is. I use the old theme for memory reasons.
-------------------- Update: * ECE: Total rewrite. Functionally similar besides missing keyboard/mouse bindings. Added font editor, project save/load. * Escheron: Changed font to the one specified at project start.
ECE2 interface, with the font editor open. There's also a viewport and some other minor stuff.
A showcase of most of the change in the font and the renderer. This includes "content" that definitely won't be in the final release.
Notes: Making a PC-side editor is a helluvalot more involved than I thought it would be. I had to rewrite most of it from scratch since the code kept getting more and more cruft until it became an unmanageable and unfixable mess. The new code feels much cleaner and far easier to work with, especially now that I know what I'm doing. At least, much more than I did before.
Things that were added include the viewport, script labels in the timeline, NPC dialog editor, and collapsible frames. The viewport can also pop-out to its own window.
Things that haven't been put back include a script editing widget, and mouse/keyboard bindings for the timeline and tilemap canvas.
The actual Escheron app had its font finally changed over to the way it was supposed to look from the very beginning. Thanks Zera . That was fast work with the newly-crafted (and at that point, awfully buggy) font editor. The returned source made its way back to the app and I modded the font routine a bit to support 1px vertical descenders.
TODO: * Escheron: -- Everything. (still)
* ECE(2): -- Add scriptable transitions to the viewport -- Add back widgets that were removed during rewrite -- Fix playback oddities -- Export a project to something Escheron can actually use
The assembled file that you attached to your post has that strange filename problem in its header, indicating that something (probably binpac8x.py) is putting that invalid name there which Wabbitemu is picking up and using.
Like Xeda said, try just having on the command line:
That's the most likely problem. If the program afterward isn't a valid assembly program and you do this, you'd get an "ERR:INVALID" error instead.
EDIT: Holy hell did the post above just change on me? Gotta run more tests, but what you're describing on your side should both NOT be happening and shouldn't be possible. How are you viewing the files? Any screenshots? I want to know where you got your emulator and tools from, and what OS you're using.
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.
I'm kinda embarrassed but I can't figure out how to reset z I've tried: res z res z,0 res f,(somenumber)
And Spasm errored each time. What am I doing wrong?
Is there a list of commands and BCALLs with what they affect? That would be really nice when programming.
Flags don't (re)set that way. They're often used to indicate additional effects of a prior operation (such as the particulars of an ADD or SUB operation, or a rotate/shift) but only the carry flag gets special treatment with "scf" and "ccf" instructions.
So in short, no there's no way to directly (and efficiently!) manipulate any flag other than the carry flag. To answer your question, however...
If you don't particularly care about efficiency, you can set the flags register to whatever you want by directly "loading" to it. This destroys all flags, register A, and whatever high byte of a pair you want to push. This uses 21+7 ccs at minimum on a z80:
ld c,%01000000 ;sets bits to load to the flags register push bc pop afYou can take a look at this page to learn the bit positions of the other flags in case you want to modify them too.
Now... if you don't particularly care about the contents of register A or the other flags you can do this to reset z:
OR A ;Reset carry flag SBC A,A ;A-A-0 = $00. ZBoth of the above solutions use 8 ccs on a z80.
As a note (and important if you're exploring other ways to try to mess with just Z), typical shift/rotate instructions (RLC C, RR L, SRL A) will affect Z like you'd think, but their more efficient single-byte version for register A (RLA, RRA, RLCA, etc.) does NOT. Had to learn that the hard way
EDIT: I lied. The bit that started with SCF was to reset, and the one with OR A was to set (post changed to reflect that). Heh. I confuse my thoughts and wording despite the comments themselves being correct.
Looks awesome! I was wondering if ya'll were taking a summer break, but it looks like you've been pretty busy! It kindof reminds me of Unity, especially once when ya'll set up a viewport window to see what the player sees. This looks like an engine you could create Escheron sequels or other tilemap games with.
It fascinates me seeing what all goes into planning and programming a game. How do ya'll know what to include when programming a cutscene or map editor? Is there an online tutorial that you've been using as a guideline and then make it calculator/Escheron specific?
This is indeed something I could use to help build other games with, tho in all honesty, I'm probably going to just teach the other people in the dev team how to use this so they can make all the cutscenes that won't require special ASM magic to accomplish.
Aside from technical stuff answered by references or Stack Overflow, no tutorials were used in the creation of this project. Beyond PIL and Tkinter, all the project's logic was put together from scratch. The main things that are chosen to go into the editor are based on the following:
1. What can Escheron already do with its cutscene script engine? 2. What sort of interface looks like it would work? 3. How to manage everything in a clear, concise and coherent manner?
For (1) we have documentation that details exactly what is available for use. For (2), I thought a little bit about how CalcGS arranged things and I remembered some extremely fuzzy details about my experience with Macromedia Flash back some 15 years ago. Then I sketched some ideas on a sheet of paper, shared it with the dev team, and got some feedback. And we're still working on (3) based on the problems encountered in actually implementing scripts in Escheron and the overall reason why we needed the editor in the first place. That reason being that it's extremely difficult to have multiple sprite objects and the main cutscene run their own scripts independently from and concurrently with each other and still maintain some sort of cohesion. I was going to say something else but I forgot what it was. I spent far too long trying to figure out what I'm posting about and now I'm going to give up. There's a reason why Geekboy gives me cherries everyday. It's because my DETERMINATION is all out.
Update: * Minor tweaks, bug fixes, and other updates * ECE (Escheron Cutscene Editor) can now allow navigation and creation of main scripts
The GUI for ECE so far. Many of the elements you see are fully functional. Still can't load or save, tho.
Notes: Aside from easily implemented fixes and updates, work on Escheron itself has stopped in favor of getting the editor up and running. Most of the stuff that's been updated in the app was done Zera (artist/author) which includes adding new tiles to the maps, use for those new bookcase tiles (game lore), and the addition of consumable spell(s)-in-a-jar. The actual programming remains my fault so feel free to blame me for everything.
The cutscene editor (which we've named ECE) has been what we've really been working on for the past month or so. It turns out that making editor software is a hell of a lot more involved than previously thought but progress with it is steady enough. The framework necessary for adding elements to a script and executing it is in place along with most of the interface needed to edit those scripts.
TODO:
* Escheron: -- Everything.
* ECE: -- Finish sprite select/edit panel -- Add viewport window to simulate what the player would see -- Add text object handling/editing -- Add scriptable map change and transitions -- Add a way to edit more than one script? -- Save/Load projects -- Export a project to something Escheron can actually use
Looking great! Love the dedication towards the art, especially shown in the speedpaint vids. I shall now show my support in the traditional CFD manner.
Show Posts
. That was fast work with the newly-crafted (and at that point, awfully buggy) font editor. The returned source made its way back to the app and I modded the font routine a bit to support 1px vertical descenders.