Just the sort of thing to show of in the Games Arcade at the London Show. I have room for a few more machines if anyone has the hardware

I've been doing some profiling to take a look at how the screen draw works and take some rough raster timings. For a start the gameplay code overhead (without moving so limited collision detection and no AI) is around 1/2 frame. The draw order is:tricky wrote:Kieran, do you think you might have room to double buffer just the bit where the player is, or at least build it off-screen?
Thanks Dave! I hadn't thought about BeebSID or BeebOPL music; I guess this would fall into the same category as the NULA version. Look forward to chatting to everyone and showing more progress at ABUG in November.Arcadian wrote:Hi, sorry it's taken me so long to pipe up in this thread, I can assure you I've been excitedly reading every update, trying out every test version as soon as they've been posted! Am simply amazed at how smooth/fast it's looking already and can barely believe how in an instant it went from mere concept sprite routines into a responsive, playable game!
Can't wait to hear the how the tunes sound once native Beeb music tracks have been composed. And do you think there could be mileage in adding options for BeebSID (using the C64 conversions?) and BeebOPL (using the PC/adlib tracks?) too?
The main problem is that the render loop is set up for double-buffering and for an extremely variable render time. Because it assumes the buffer is not being displayed the process is:Rich Talbot-Watkins wrote:Nice work Kieran, it's really coming on well!
Just to be clear, how is the sprite erasing currently working? Are you storing screen bytes before plotting the sprites, and then just copying them back over the top to erase? (i.e. a direct store, rather than the Exile type routine).
I feel there must be some other trick to reduce the flicker. In the most common case, where the character is stationary, with nothing in the foreground, there is still a lot of flicker (some due to not syncing with VSync, but still...). The player, in a standing position, is not that big (looks like 3 characters wide by about 32 high) - I would expect, even with a slow plot routine, to be able to flickerlessly draw that, provided the erase were fast. Have you tried profiling the plot routines (even just with changes to palette 0 to be able to get a vague idea of scanline count)?
Nothing, just a good old fashioned macro for setting the background colour.Matt Godbolt wrote:Re: profiling...what do folks use for profiling? I just realised there's a golden opportunity to add something cool to jsbeeb for profiling purposes, and wondered if other emulators already have this?
Code: Select all
hits={};
processor.debugInstruction.add(function(pc){hits[pc] = (hits[pc]||0)+1;});
Code: Select all
hits
Object {56348: 4156, 56350: 4155, 56351: 4156, 56352: 4156, 56354: 4155, 56356: 4155, 56467: 4156, 56468: 4156, 56470: 4156, 56471: 4156, 56472: 4156, 56473: 4156, 56474: 4156, 56475: 4156, 56477: 4156, 56478: 4156, 56480: 4156, 56481: 4156, 56482: 5825, 56485: 5825, 56487: 4156, 56489: 1670, 56491: 1670, 56492: 1670, 56541: 1670, 56542: 1670, 56545: 1670, 56546: 1670, 56555: ...
Code: Select all
_.last(_.sortBy(_.pairs(hits), _.last), 20).reverse()
Code: Select all
> utils = require('utils')
> _.each(_.last(_.sortBy(_.pairs(hits), _.last), 20).reverse(), function(x) { console.log(utils.hexword(parseInt(x[0])), x[1]); });
12bf 385525
12bd 385503
40dc 11480
40db 11480
40d6 11480
40cd 11480
40cb 11480
40c8 11480
40c5 11480
40bc 11480
40b9 11480
40b6 11480
40de 11479
40d7 11479
40d4 11479
40d1 11479
40ce 11479
40c9 11479
40c2 11479
40c0 11479
Hey Chris, I wasn’t ignoring your comment - I wrote a reply and my dodgy train WiFi lost it.cmorley wrote:Perhaps you've considered this but if not..
Do all the sprites need to be redrawn every frame? Perhaps you could interleve non player sprites on odd & even frame redraws, like the torches? Can you cull plots which would put the same sprite & animation frame in the same location as the previous frame - like the player standing still? Then there would be no flicker on static actors even if there is some flicker on motion.
+1 like for the development 'blog' posts. I enjoy reading them.
Thanks Matt! I will cross reference against the assembly in err, two weeks. I expect you to have a full 6502 profiling toolkit written by then.Matt Godbolt wrote:This is what I got for PoP on the idle screen:
...I suspect batching by 8-byte blocks or similar might be better (or more likely some actual visualisation...)
I'll see what I can knock up!
Since the original game runs on an Apple II, and there have been C64 + CPC ports already, I'm loathed to require more than standard 128K (or require a cartridge / ROM like the C64 does.) I guess I could do an "enhanced" version if there was an extra 16K SWRAM available, since we're getting into custom build territory with a NULA version anyway. 6502 copro doesn't help either because it's so hard to get (good amounts of) data down the Tube.RobC wrote:Looking forward to seeing this![]()
Given that it's already Master-only, is it worth thinking about just requiring an extra 16K of sideways RAM? I'm guessing that many Master owners have a cartridge that gives RAM in slot 0/1 or 2/3.