Stealing the secrets of the NES - Agon Light Tilemaps in C

[@ncot_tech]

@learnagon points out that "In 14:50 you say 27, 3 and I see putch(23); putch(7); putch(3); putch(1); putch(1); is this a typo or should it be 27, 3?" The code is correct, I said the wrong words, even though I was reading them out 🤦‍♂

[@MadsterV]

pro tip: modern 3d engines also do not draw whole tilemaps offscreen. There's a culling stage where triangles that fall outside the render viewport are discarded.

[@vruz]

Excellent work, James! Congrats!

[@braveitor]

Nice video and explanations. Those old programmers where really clever.

[@arronshutt]

Nice cat shirt. Although the beard seems to be a lot shorter :) Very impressive video. I think that you should be able to do some kind of scrolling platform shooting things fairly easily. Seems odd to me that the Agon Light is not more fully featured for writing games on, but I guess it just needs more code to overcome the various issues with the demo that you put together. But, looking good for doing a proper game on :)

[@Roxor128]

Makes me think of the tiling engine used by Commander Keen. It writes tiles into EGA memory and uses the hardware to scroll around. The hardware can only scroll so far, so the game writes tiles to video memory just off the edge of where the screen is scrolling to, plus replacing tiles where sprites in the main screen were before drawing new sprites.

[@archibaldbuttle7]

hey James - another excellent video - nice work! you're right that using VDU 23,27,1... to copy an area of the screen to a bitmap will only work with 8-bit IDs - which is why there's also VDU 23,27,&21... which works with 16-bit IDs 😁 another thing - it is possible to only plot part of a bitmap. if you set a graphics viewport, then a bitmap plotted using PLOT &ED will only draw pixels within the viewport. (NB this isn't true if you use VDU 23,27,3 to draw bitmaps). just set a viewport to be just the column(s) revealed on the screen edge and then use your existing loop to plot the edge bitmaps - the underlying code in the VDP deals with the clipping and will give you a bit of a speed boost. you'd just need to remember to clear that viewport afterwards. (or use the multi-context API to swap between contexts and remove the need to set and clear the viewport, just have one context with that viewport set, and a different context for other things - it's a shorter command to change contexts 😉) for drawing things like this it can also be a good idea to switch to using pixel coordinates, rather than using OS coordinates. it makes dealing with the Agon's slightly wacky OS scaling somewhat easier. btw, if you're after more performance, vertical scrolling is much more efficient inside the VDP... and RGBA2222 format bitmap plotting in 64 colour modes is inherently the quickest... 😀

[@ncot_tech]

I'll have a play with viewports and stuff at some point. A vertical scrolling shooter seems like a fun thing to try and make.

[@SmashCatRandom]

Nice video :) I've written a game engine for the old Arduino UNO 8-bit (16Mhz, 8bit, no video or audio), which drives composite output at 50fps, with split/full screen scrolling, sprites and a tile-map background with a resolution of 256x256. I've converted a couple of arcade games, including the scrolling Scramble, and the ZX Spectrum game Manic Miner to run on it (that one was a challenge as the 32K of the Arduino had to run the 48K spectrum game :) ) In my case I don't have nearly enough memory for a frame-buffer, so generate each scanline on-the-fly (AKA "racing the beam") using ASM to ensure it's cycle-perfect to match the screen refresh. The Scramble game and other demos are on my channel (flickering is just due to recording the screen with my phone - in real life they're super smooth).

[@MrGareth1973]

Great video. Thank you!

[@LearnAgon]

Enjoying this new video very much, thanks 🙏 🎉

[@LearnAgon]

In 14:50 you say 27, 3 and I see putch(23); putch(7); putch(3); putch(1); putch(1); is this a typo or should it be 27, 3? Gracias 🙏

[@ncot_tech]

@@LearnAgon it's 23,7 I said the wrong words, the code is correct.

[@Jackpkmn]

I'm hoping that you go into the whole super mario bros biggest smoke and mirrors thing is that there is no level data as we would conceptualize it. The game works like a little assembly line that constructs the whole game world on top of a endless pre-formed void right before it's rendered to the graphics buffer. And that thinking about trying to go backwards in a level in SMB creates the absurd concept of how to run an assembly line in reverse.

[@AlexEvans1]

I presume there is a reason why you aren't using the Agon's "hardware" sprites for your sprite.

[@ncot_tech]

I need to have a play with those, although according to the docs for the Console8 firmware which I use, it says "For completely optimal graphical performance, it is usually best to avoid using sprites, and instead use the bitmap system directly. Using a small number of sprites can be a reasonable compromise." agonconsole8.github.io/agon-docs/vdp/Bitmaps-API/

[@delphicdescant]

I get a kick out of your disdain for Mario.