Jump to content

Andrew Davie

  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Andrew Davie

  1. 40 minutes ago, rbairos said:

    I should get you to download and compile the encoder from the github.

    I'd be delighted to do that, thank you, but...


    40 minutes ago, rbairos said:

    ColorizeTOP.cpp  compiles into a dll.  Which is the plugin I wrote for the free version of TouchDesigner.

    I don't think MacOS handles "dll"s; would I need to do anything different for this OS?


  2. 43 minutes ago, rbairos said:

    So here's the same clip with no enhancements.


    TY. It's quite good, IMHO.  Obviously darker/less contrasty.

    I had a bit of a "what-if?" idea and the first thing I'd suggest instead of putting a contract/brightness filter step in, I'd simply modify the values of the '2600 palette so they were ~1/2 as bright. That way it would choose brighter colours, effectively brightening things at a 0-cost for extra processing time. But instead of exactly 1/2 (i.e., one frame with colour and the next blank), I'd take phosphor fade into account and maybe set it to something like 75%. Worth a try?


  3. 1 minute ago, Thomas Jentzsch said:

    But that's what you should do. The signal bandwidth is massively reduced on a 2600 display. So you have to make use of it as good as possible. E.g. you should do Chroma subsampling to take "advantage of the human visual system's lower acuity for color differences than for luminance".


    Also formulas used for converting RGB into grayscale (luma) prioritize green a lot. E.g. {\displaystyle Y'_{\text{601}}=0.299R'+0.587G'+0.114B'}



    Yes, I'm sure you're right. But let's have a look-see at some test examples anyway?

  4. 2 minutes ago, Andrew Davie said:

    Well, I disagree here that it's your job or correct to do this. If it were alternating, I'd want the effect to be exactly the same to the eye as it would be without adjustment. That is, we are not looking to "fix" things for the eye; we want to present the eye with the same thing as it would have seen anyway. If it's alternating then let the eye do the "averaging". If the eye "loses" stuff, so be it... that's what would happen with the original, too.

    I'm not sure what I'm suggesting is going to be better. But I'd really like to see a comparison between the two!

  5. 1 hour ago, rbairos said:

    If the scene were alternating between full green, and full blue, squares, you'd still want the average to be more green than blue, I'm thinking.  Green has more of an impact visually.

    Well, I disagree here that it's your job or correct to do this. If it were alternating, I'd want the effect to be exactly the same to the eye as it would be without adjustment. That is, we are not looking to "fix" things for the eye; we want to present the eye with the same thing as it would have seen anyway. If it's alternating then let the eye do the "averaging". If the eye "loses" stuff, so be it... that's what would happen with the original, too.

  6. 49 minutes ago, rbairos said:

    Yah you were right.
    My 'enhancement' stage was being too aggressive.
    I think I tone it down quite a bit now that these potential improvements are here:

    Original, with 100% custom enhancement filter, then encoding.
    Bottom row, no enhancement filter, then encoding..


    This looks much better to me. The yellow/white are now well separated.

    Will be interesting to see the results of seeing it in action.


  7. 4 hours ago, JeremiahK said:

    (I updated my dasm, and it still mentions NO_ILLEGAL_OPCODES as an unresolved symbol, but that's not really a problem.  It's better to be informed, while knowing it's not a problem, than to not know if it actually is a problem.)

    This one is a bit of a special-case.  Yes, it's an unresolved symbol but technically it's not referenced (in a way that requires resolution to a value) so it isn't an error. It is reported as part of the symbol table (correctly) as a symbol which has not been resolved, but which is not preventing successful assembly. In my opinion, it belongs in the symbol table exactly as shown, dasm is doing exactly the right thing.



    • Like 2

  8. 5 hours ago, rbairos said:

    In both cases, I weigh green 60%, red 30%, blue 10%.

    I know the eye sensitivity for colours is the thinking behind this, but I am not understanding why the above is necessary here.

    This is just going to skew the colours, no?  Have you tried just a simple average?


  9. 40 minutes ago, rbairos said:

    In the above, the same colors its picking for encoding are the same colors its displaying.
    So what I think is going on, is I'm preprocessing the colors too much.
    I made a patch that plays with gamma and contrast, and tries stretching out each red,blue,green range independently to its max.
    Maybe I should relax those now that the color selection is improved.
    And use your screenshots as a guide.


    Also, as an aside, my observations are that intensities are not the same for all colours.  That is, brightness of 14 is not the same for colour x as it is for colour Y.  White is, for example, quite bright even at intensity 10.  Blue (say, colour 8 ) is not nearly so bright. So perhaps your conversion may need to take this into account, too?  I guess I'd do it by getting the Stella palette RGB values (at least it's a starting point) and using those for doing the matching.  In my experiments in displaying images, long ago, I found that indeed stretching the range and increasing contrast made a big difference.

  10. 37 minutes ago, rbairos said:

    Here's the next test with the better foreground separation.
    Note in this case, it includes the simulated 60-hz checkerboard flicker, so its best scene at 720p60

    Well firstly, this is magnificent. Amazing job; I'm in awe.


    I have reviewed and I think/hope there are some minor improvements you can do. I have observed that the yellow is too bright and almost white, so you lose a lot of detail in yellow/white areas. And the purple/blue choice seems to be incorrect. I've grabbed a couple of screenshots where this is (to me) clearly apparent. If possible, I think a review of the RGB to '2600 colour choices you are making might improve the visuals even more. Of course I may be misunderstanding the capabilities, but I'm hoping...





    In the above, the purple platform is a poor match.




    Another instance with platform colour choice, and also here the red pit is very yellow instead of red/pink.




    Here, the yellow is not contrasting enough - a shade darker would be nice.




    Again, yellow a shade darker might work...?



    So, well done again. Hoping you can find even more improvements. What a great bit of work :)



  11. 20 minutes ago, rbairos said:



    Huge improvement.  I really want to see some more video material!

    Also, wanted to ask if you carry pixel errors across frames to give some time-based correction there?



  12. On 3/7/2021 at 3:45 PM, Andrew Davie said:


    An aside; my printer give vertical lines/ripples on the sides of things as they're printed. I just found out this is actually the stepper motors causing it, not (as I thought) the belt vibration.  It can be almost eliminated by printing walls very slowly. So, if you have the same issue then try setting your outline/shell speed to something low (say, 10mm/s). It makes a huge, huge difference for me.



    Yeah, nah. The vertical lines were actually because I didn't have the extruder holding tightly enough onto the filament, and the toothed feed wheel occasionally ground off some filament instead of pushing it through. It was a bit of slippage. I happened to clean the whole mechanism and when I put it back together I noticed the residue on the teeth and figured "tighter will stop that", and what do you know - my vertical lines on walls went away.  It was hard to find because the lines were aligned, and I didn't grok that the extruder could cause that. Well anyway, now walls are very smooth for me so that must have been a major contributor.

    • Like 1

  13. 54 minutes ago, ThatGuyMike said:

    Also worth noting that a 'programmer of the year' award would probably never go to a game developer. 

    Game programmers do great work for sure, and there are a handful of those programmers who are freaking geniuses. But awards going to games instead of say, robotics? Neural-net based AI? Spacecraft navigation? Are we really expected to believe that another console shooter won an award over full operating systems and software?


    At least during my tenure as a games developer (1984-1995ish), we were anonymous as programmers. There were a few big names we'd heard of mostly from the UK, but they were few and far between. The games occasionally got awards - not many - from magazines, but I'd never heard of the idea/concept "programmer of the year" or even who would award such a title.  So for me, it's not something that I knew about back in the day.



    • Like 3

  14. 2 hours ago, cfarl said:

    Al_Nafuur, just to know....


    You have to use the elf file to program the STM32F407VGT6 with STM32CubeProgrammer, right?


    As far as I am aware, you can use either, but it's easier with the elf. With the bin you need to set some of the programmer addresses correctly. Vague here - I just use the elf these days. I have previously used either/both. Al will confirm/correct.


    2 hours ago, cfarl said:

    I can use this same pcb without the ESP8266 to program UnoCart firmware? 

    Yes, if you're using the dual Uno/Plus board. It's compatible with both. Or all three, if you think of it as UnoCart, PlusCart, PlusCart SD.









    • Like 1

  15. It's in my long-term plans to make an offering on NFT. I just haven't had a "product" that I can sell yet. I'm a bit disappointed not to be "first" but at least I guess I won't cop the flack from making the choice. I like the idea of embedding royalty payments; one of the things that bothers me is seeing something I've sold for (say) $75 -- and for which I actually take-home something under $10 -- being upsold by someone else for $1400 and I see absolutely zero of that profit.  A good summary of the current state of royalties on NFT: https://www.nft-innovation.com/post/how-do-nft-royalties-work. It seems that the royalty implementation is not yet mature, but in principle I very much support the concept of NFTs providing some continuing royalty payment to original artists. For example, we don't seem to shirk at musicians and songwriters being paid for their creative works - so why not game developers, too?


    • Like 2

  16. 1 hour ago, Thomas Jentzsch said:

    Tried to follow the NFT stuff in the show. All I got is, that a NFT is a convenient way to create virtual and artificial rarity for non-rare stuff. 


    Maybe I am too stupid to understand, but my summary is: "Let's milk collectors.". Please correct me, where I missed the point.


    As I see it, it provides an effective certificate of authenticity, exclusivity, and ownership that is indisputable and permanent.




    • Like 2

  17. One addition to the instructions -- change the layer "fill" direction from the diagonals to orthogonal to the cartridge.  That is, instead of building each layer diagonally, make sure it's at right-angles. These are slicer settings, of course. It's important for the strength of the lip and other parts.


  18. The updated design/STL files for the shell are now up at...




    I have just regenerated the STLs for this push, so I have not tested the print, but they SHOULD be identical to what's shown in the video, above.


    If you don't know how to do the two-colour prints on a one-colour printer, PM me for instructions.


    1. FRONT/LOGO are the two parts of the two-colour print for shell

    2. LABEL/LETTERS are the two parts of the two-colour print for the label

    3. I advise putting a skirt of size 10 around the PINS (with separation of 0.6 mm) before slicing.

    4. Everything is designed for slicing and printing with an 0.4 mm nozzle at layer height 0.2 mm or below. 


    The pads are designed to improve your yield rate when printing, by keeping the prone-to-curling-up corners firmly on the bed. The pads should peel off very easily post-print. Just flex them back and forth along each axis, and then peel off.


    1. FRONT/PADS should be sliced as one unit and printed together.

    2. BACK/PADS should also be sliced as one unit and printed together.

    3. For both of these, just set X/Y/Z to the same values in your slicer, so the pads are positioned correctly.


    If you print one, please please post a picture of your print here. It's the very least you can do for me as a thank-you.

    Suggestions for improvements in the design are welcome.


    • Like 4

  19. 9 hours ago, Propane13 said:

    is it possible to have a planet scroll up/down besides left/right?

    More difficult because of the axis of spin. It's possible, but not with my current code.  The math is slightly different. Remember I'm just effectively "drawing" into a bitmap, so just about anything is possible if you can figure out the math and make it fast enough.


    9 hours ago, Propane13 said:
    • does the background have to be black, or could it be another solid color, or even a textured background?

    The background can be textured, with some minor modifications to the existing code


    9 hours ago, Propane13 said:

    The reason I ask-- there may be some simple mechanics here that could make for an interesting "roll the ball" kind of game.  Since Playfield is a bit tedious to scroll sideways, I was thinking it might be interesting to try a simple vertical scroller, where the ball "rolls".  It rolls over certain power-ups, it gets bigger or smaller.  The ball could get smaller to fall into holes/tubes and pop out the other side, and get bigger to "climb over" walls.  Before thinking about it too hard though, I thought I'd see if any of the above is possible with the current engine idea.

    Well, sideways scrolling isn't tedious anymore with CDFJ.  It's pretty straightforward, actually.  I'd encourage you to pick up @SpiceWare's demo code and go from there.  Takes a little while to wrap your head around it, but worth the effort. I think my coding-head is wired differently because both that code, and some of the other code I've worked with recently (e.g., PlusCart) are just different to how I do stuff. Not wrong, just very different architecturally.


    9 hours ago, Propane13 said:

    Great demos so far, btw!

    TY, it's been fun.




    • Like 1

  20. 2 hours ago, Fierodoug5 said:

    I haven't printed this version of the shell yet, but some hot glue should hold that logo in just fine I would think. 

    Please don't!  I have a refined version now that completely corrects all of the weaknesses identified in earlier versions.



    * Fit was tight, and obviously didn't fit some machines.

    * masking 'lip' printed with 2 lines wide and was too fragile

    * logo insert was not strong enough to survive mishandling

    * label difficult to insert on assembly

    * pins VERY difficult to insert on assembly




    * the shell is 0.5mm wider to accomodate variance in cartridge slot fit.

    * the logo is once again printed "in situ" rather than as a post-print glue-in. This requires a filament swap during print, but in the long run it's not much more pain than welding/gluing in the logo... and it looks way better anyway.

    * The tensioner "ramps" at the bottom of the cart are removed - again, allowing for cartridge slot variance

    * the "rail", or "lip" as I call it, is now exactly 1.6 mm wide, allowing a 0.4 mm slice to fit in 4 rows. This makes them super strong.  The lip both masks the join but also acts as a first-stage shell seal.  That is, you can have the shell (weakly) snap shut using the lip alone, without using any of the pins

    * The lip is extended in length so it covers more of the join on the side.

    * the walls are increased in thickness to 3.2mm, giving a good 50:50 ratio on the lip overlap. It sounds thick, but looks great on the printed thing.

    * I'm printing at 0.2 mm layer height (the failed batch were at 0.3 mm layer height).  This makes a huge difference in strength. Also print speed blows out by 50%, but that can't really be helped in this case.

    * The slot for inserting the label is now deeper, so label insert is way easier when assembling.

    * The pin mounts/holes are 0.1 mm wider/longer which doesn't sound like much, but it makes the pins super-easy to insert now, but still tight

    * I print with "pads" which are just adhesion-aids to keep the corners on the bed. These pads just peel off post-print. In the video I haven't yet cleaned the print (it's exactly as it came off the bed, but with pads peeled off)... so there's a bit of residue on the corners where the pads were. The pads significantly increase print yield for me from about 40% to maybe 90% or more.


    So anyway, because of all these changes and because the new design is so much better... I recommend holding off on any printing with earlier versions. Here's a video-look at the new design, assembled. It probably doesn't look much/any different to previous versions - but it's really quite lovely. This particular print is probably one of the nicest/cleanest I've ever done. And I've done, literally, hundreds.




    • Like 6

  21. 1 minute ago, SvOlli said:

    Yeah, yeah. Always on the non native speakers... "right" as in "opposite of wrong". But most EPROM programmers want notch neither left nor right, but at the top... 😛

    I was just being pedantic because it would be a shame for a simple ambiguity to cause loss of this ROM.

    • Like 1
  • Create New...