also posting this here: investigating an unexpected binary size reduction when replacing a bunch of C++ code with C code in the Oryol Gfx module: floooh.github.io/2018/05/01/cp

more like mastodon.8bitretrogamedev.place, buts whatevs :) I've started a Z80/M6502 assembler in Typescript, with the long-term goal of a modern 8-bit IDE for my home computer emulator as VSCode extension: github.com/floooh/hcasm (Per Vognsen's Bitwise project finally pushed me over the edge and convinced me that lexing/parsing isn't the voodoo-magic I thought ;)

big update to my 8-bit emulator: the chip emulators are now in separate dependency-free C headers, Z80 emulation is now (machine-)cycle-perfect, the Amstrad CPC emulation is much more precise, the web version defaults to WebAssembly. github project: github.com/floooh/yakc, wasm version: floooh.github.io/virtualkc/

I have changed the license of the sokol headers (sokol-gfx and sokol-time so far) from MIT to zlib/libpng: github.com/floooh/sokol (cc @rlyeh )

...there are countless topics on the Unity discussion forum about his, but most recommend to mess around with pivots in max, or after the import in Unity, I wonder if there's a simple "Y points up" in the Max FBX exporter which fixes this more in a more robust manner...

Unity/FBX/3DSMax question: what's the best/cleanest fix to get rid of the -90 X-axis rotation when importing 3DS-Max-exported FBX files into Unity (also for animated characters), is there an FBX exporter option, or is artist intervention needed?

New approach how emulated chips talk to each other by simulating the system bus pin connections. Involves running the finger through wiring diagrams like this: z1013.de/spl/z1013-64_2.gif :) (here's how I understand this so far: github.com/floooh/chips-test/b)

Z1013 emu example complete now with keyboard input and preloaded BASIC, 259 lines of C (not counting blank and comment lines): github.com/floooh/chips-test/b mastodon.gamedev.place/media/9

it's kind of surreal that the entire Z1013 operating system (with text console, debugger with register dump & breakpoints, cassette loading, etc...) is 2 KBytes and fits into a 130 lines hexdump: github.com/floooh/chips-test/b

simple 8-bit emulator sample (a Robotron Z1013) for my new cycle-ticked Z80 emulator, kbd input missing (will add about 100 loc) GLFW+flextgl+sokol_gfx+chips: github.com/floooh/chips-test/b mastodon.gamedev.place/media/e

PS: to clarify I didn't have problems with a variable QPF frequency so far, but I also didn't look very hard

I have created a very small standalone C-header for cross-platform time measurement (currently Win, OSX, Linux, emscripten): sokol_time.h (github.com/floooh/sokol/blob/m)

...in "Z80 speed" the old instruction-ticked Z80 emu is running as fast as a 1.2GHz Z80, vs about 300MHz for the new cycle-ticked emu (on my mid-2014 2.8 GHz i5 MBP with clang -O3)

ok, got the time for running ZEXDOC+ZEXALL Z80 tests to under 300 seconds for the new cycle-ticked emulator (from 538 secs), still nearly 4x slower than the instruction-ticked version (which is 76 secs), but pretty ok now considering that an indirect call happens every few host-CPU ops mastodon.gamedev.place/media/q

I think I'll do some optimization attempts first before going on to the wait-state and interrupt handling. This is what the ZEX-test runner looks like (just needs some RAM and 2 CP/M system calls for char and string output): github.com/floooh/chips-test/b

Show more
Gamedev Mastodon

Game development! Discussions about game development and related fields, and/or by game developers and related professions.