Jump to content

Andrew Davie

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Andrew Davie

  1. 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.
  2. Well, that's astounding.
  3. 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.
  4. 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. 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.
  5. 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?
  6. As I see it, it provides an effective certificate of authenticity, exclusivity, and ownership that is indisputable and permanent.
  7. 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.
  8. The updated design/STL files for the shell are now up at... https://github.com/andrew-davie/PlusCart.git 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.
  9. 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. The background can be textured, with some minor modifications to the existing code 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. TY, it's been fun.
  10. Please don't! I have a refined version now that completely corrects all of the weaknesses identified in earlier versions. Weaknesses; * 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 Fixes... * 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.
  11. I was just being pedantic because it would be a shame for a simple ambiguity to cause loss of this ROM.
  12. It's a bit confusing -- "shortened" is the word we are looking for here
  13. And by "right side", I'm sure you mean "correct side" ... not necessarily the side on the opposite of the left side
  14. Such a shame... but all of these... into the rubbish bin they go.
  15. I've had a report of one of the new PlusCart shells with a few problems. Primarily it was not a good fit and needed to be pressed very hard to insert to the VCS. However, this treatment apparently caused the logo (which is a new, welded, design) to separate. So, that's not good... not good at all. Please be aware that if your PlusCart shell is faulty in any way, I stand behind the products I produce and will of course offer you a full refund or replacement at my cost. As to further developments, I'm now inclined to abandon offering any shells, and instead require anyone wanting one to get their own printed. It's just not worth the hassle/stress.
  16. The menu displays use very precise timing and knowledge about how a real '2600 TIA chip actually works. If the FB2 is not emulating the TIA chip almost exactly, then this is the source of the display glitches/corruption. In other words, nearly certainly a FB2 fault, in my opinion.
  17. ESP looks as if it's installed correctly. Next I'd be checking the continuity from the ESP pins to the appropriate pin on the STM.
  18. Can you show some views of your board so that I can check the basics?
  19. I seem to prefer doing demos than completing projects. I like pushing the envelope, not sealing it up and posting the letter. Nonetheless, here's a thread where I hope to post some demos of my Chronocolour(TM) Software Sprite System. I developed the basic playfield-based software sprites for my "WenHop?" project, but first as a simple test-bed sub-project where I could put some animating playfield/software sprites onscreen. So, see the attached binary. It is probably overtime on hardware, so best to view in Stella only at this stage. My immediate plans are to write a simple tool to convert from an image file to the format used for the software sprites. That should be quick and easy, but I just don't quite feel like doing that right yet. Soon. Here's the format... const unsigned char rocketShipFlame2[] = { 1, // width in BYTES (=8 pix/byte) (MAX =4) 21, // height in SCANLINES (pref multiples of 3 -- TRIPIXs) 3,0, // center point (PIXELS) from 0,0 top left ________ ________ __XXX___ ________ ________ __XXX___ ________ ________ ___X____ ________ ________ ___X____ ________ ________ ___X____ ________ ________ ___X____ ________ ________ ________ }; So, a basic byte array with a simple header 1) width in bytes (each byte being 8 PF pixels), so maximum sprite width 32 pixels 2) Height in ChronoColour(TM) scanlines. Note this should be a multiple of 3 3) pixel x,y offset of centerpoint of sprite. 4) the shape data Sprites are drawn using a simple call... void drawBitmap(const unsigned char *bmp, int x, int y, bool relativeToScreen The clipping to the screen window is automatic. The 'relativeToScreen' allows for scrolling windows into a larger playing area The shape data is just a series of byte triplets (ChronoColour) for each line. Red/Green/Blue or whatever colours you have chosen. For shapes > 1 byte wide (i.e., >= 8 pixels) you just define the shapes side by side... for example... const unsigned char flagUSAandUSSR[] = { 2,15,0,0, X_______ ________ X_______ X_______ _XX_____ XXX_____ X_______ X_______ X_______ X_______ _XX_____ XXX_____ X_______ ________ ________ ________ XXX_____ XXX_____ ________ ________ ________ ________ XXX_____ XXX_____ ________ ________ ________ ________ ________ ________ }; Believe it or not, that last one looks like two flags - USA flag and USSR flag - side by side. Low-resolution ChronoColour(TM) PF graphics are a bit of a black art... As the binary shows, the basic draw systems are functional. This particular version is just drawing both those ships every single frame (i.e., 60Hz) but since starting work on this I have implemented a double-buffered graphics testbed. That is where we have two graphics buffers - one being displayed on the screen, and an invisible one into which we draw stuff. When drawing is finished, we swap the buffers around. That allows you to draw things over more than one frame, and get lots, lots more onto the screen. I'll get that in soon. I hope to release the source code and conversion tool rather soon, too. So, the ships above - they are actually each more than one sprite. The Flag, for example, is a separate sprite which is drawn after the ship. This allows parts of the sprites to be animated separately. It's an optional thing -- they are conjoined, so to speak, because they share a common origin point, so all parts of an object are drawn at the same x,y position - they just happen to have centerpoint offsets. Now my immediate plans after I've written the aforementioned graphics conversion tool.. is to put in a whole bunch of animation frames, to see how animation look in ChunkyColour . I'm not entirely sure it will work, but I'm keen to give it a go and see. For the first test, I'm thinking of working on some fighter sprites... and I've gone through the basics of creating a few frames from online source sprite sheets just to see how it looks "on paper"... One of the neat things about the system is that it automatically creates a "mask", so that each triplet ChronoColour pixel is actually drawn over the top of any background rather than merged with it. Another way of saying this; if a ChronoColour pixel is non-zero (black), then first the background pixel is erased, so that whatever colour the new pixel is (even if one or two scanlines of that pixel are blank)... will be preserved. The upshot is that things are drawn with priority, so the last thing drawn will always be on top of earlier stuff, with no blending. This means, though, that you lose black as a valid colour. On the other hand, the system also allows you to include your own mask, so it's possible to have actually 8 colours plus transparency... at the cost of the extra data to define the mask. I'd love to do a fighting game, or maybe a wrestling game with many large wrestlers going at it at once in a scrolling arena. Something like this.... Of course on the '2600 the screen would be a small window into all that mayhem. The frame rate may be a bit low with that much going on and we'd only have 7 colours + black.... but with the double-buffered draw it would not flicker. Thinking about it, though, you only draw stuff that's visible, so it wouldn't be that slow after all. The system already pre-culls the draw of offscreen stuff, so perhaps that many wrestlers at a relatively high frame rate might work. But first, it's going to be interesting to see how well the really low resolution works for animating people-sprites. A static image isn't going to be the greatest representation, but here's an idea of pixel chunkiness... The actual experience would be halfway between these two examples. Why halfway? It's to do with the odd triple-line colouring that ChronoColour uses, and the difficulty of showing it correctly with a simple quick-n-dirty conversion. That was a hand-converted sample. I took the original, reduced X (only) to 30% (aliased), then downsampled the colours to the preset 8-colour palette (dithered), and then scaled up X (only) to 330%. That's roughly what the tool would do, but with adaptive numbers. I imagine some hand-pixel-pushing would make the frames much nicer. Another option I'm thinking about is using a sprite overlay for the head area, of much higher horizontal resolution. For a later version, maybe, but an interesting idea. Well that's it for a start. Basically a system to draw an arbitrary number of sprites into a double-buffered bitmapped buffer with inbuilt pixel shifting, masking, and clipping. In the long run I'd love to see it as a sort of template which could be used by others to write software sprite ChronoColour(TM) games. If I find the motivation, I'll post more updates here... and of course hopefully a conversion tool and source code soon. css20210822.bin
  20. Printer's humming away doing new prints at this very moment!
  21. Different colours might be possible. The design is improving all the time, too.... tweaks to strengthen, streamline, etc....
  22. Yes, sometime soon. The planet spinner works on the real thing now. I want to get some gameplay going before releasing a demo for that. But it's really close and although it might jump occasionally because the timing isn't as refined as it needs to be, the fundamentals are working fine on hardware now. I have long-term plans for PAL, but that will be late in the piece.
  23. https://archive.org/details/AtariGameRecorder
  24. Noted. In any case, shoot me a mailing address and I'll send you a 3D shell so you can evaluate the basic design concepts in actual physical form to assist with your own shell design. I believe the design I have is pretty good.
  • Create New...