Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Irgendwer last won the day on March 1 2018

Irgendwer had the most liked content!

Community Reputation

1,517 Excellent

About Irgendwer

  • Rank

Profile Information

  • Gender
  • Location

Recent Profile Visitors

15,947 profile views
  1. 1. Lords of Conquest - heard many good things about this game and rating on AtariMania is high. Think it makes only sense with a second player (?), but didn't find anyone interested yet. 2. Frogs and Flies - the funny animation and the two player mode lead to a quite a lot of rounds - esp. while my children liked this game too 3. James Bond - the graphical diversity doesn't help to improve the boring game play. Back then, I was quite disappointed what was offered under the promising "007"-label. Still wonder about the high "7.9"-rating on AtariMania. (The picture insertion function of the new forum is great! Should be more used here... ...esp. for not so famous titles...)
  2. On PAL TV systems this isn't related to "eye trickery", but (ab-)uses the way the system works with it's halved and averaged color resolution. The color on screen is a real solid mixture of the lightness and hue and not produced by human interpretation. (The same is true for use of "NTSC-artifacting".) TV Input: PAL output: Source: vincent-van-gogh-sternennacht-ca-1889.xex
  3. Maybe the addition of "S.A.M. Painter" (Gr.15 + DLI) makes sense - as this application supports the ST-mouse too: Have not a download source at my fingertips, could somebody else can chime in...?
  4. Irgendwer


  5. Maybe this is a very wild guess, but I can imagine that the deadline of ABBUC's software contest keeps some members busy and prevents participation here. (I hope so... ) - At least the trophy money and conditions are very attractive this year. (That said, I will not manage to submit something.)
  6. "Maxi Golf" has also a course designer. http://www.atarimania.com/game-atari-400-800-xl-xe-maxi-golf_3268.html
  7. For the typical low-fi samples on "our" machines: Quantized delta encoding. Halving exactly the data size. Edit: That said, you have to go for for at least 15kHz replay to cope with the aliasing effects. If the replay frequency is lower, going for 2 bit raw data isn't that bad: Edit 2: Of course it depends if you like to depack the data on-the-fly while replaying or are able to inflate the data before playing. Both principles above are for real-time preparation of the data, saving RAM and not only floppy space.
  8. So if José thinks the same nothing would be won to use this word - so no need for it. Regarding your question PM vs playfield graphics: What about "Stealth"?
  9. Please be aware that if it's free speech and not an insult (asking myself what then an insult would be?), you may "receive" this term from others too. Maybe multiple times. From different individuals. So I would abstain to use that - even it seems sometimes fitting quite well...
  10. Yes, but if the source data is bigger than the available target buffer memory (->streaming) you've lost. So you need something like windowing the data for the compression or no self-referencing at all.
  11. Three years ago I've created "autogamy" and used it to compress the level data for "dye". (Also used in "E-Type".) Features: * fast and compact depacker (using self modifying code) * nearly as good as LZ4 - for small files often even better * in-place decompression if the source data ends at least 4 bytes behind the end of the target buffer * compression uses also self-referencing - so no streaming (windowing currently unsupported) Archive contains packer for Windows (exe) and source-code for de-packer cc65 header / ca65 source. You may like give it a try. Autogamy.zip
  12. Thanks! I will see if I find the time to go for a single file output. Normally this would require to produce the information for offsets to the frames too. (Ideally hi- and low-byte separated tables...) Don't expect too much in the nearer future while a simple shell script should also be able to join the files... Direct C-source output is out-of-scope for me, as this would open an additional construction side - and xxd does a solid job. You may get the notion that I favor small, somewhat connectable tools instead of producing a jack of all trades device. Thanks Mark, for explaining the reason for (non-)handling of palettes. And thanks to all who liked my content and just "elected" me this way into the exclusive lodge of users with more likes than posts!
  13. Ok, to be called "Sir Irgendwer" sounds quite tempting (hoping you really meant "knight"...) So here I am: img2sprites is a command line tool which is quite untested (please do so) needs badly a more verbose documentation than my facts here (any volunteer?) is a .NET console application developed under Linux with Mono but (should) work flawlessly under Windows too is executed with a filename as argument this filename is the input image, .NET (should) support BMP, GIF, JPEG (not really suitable), PNG & TIFF the top most line in the image has to contain the translation palette from left to right, the leftmost pixel is the background color theorder of the other colors decide which index the color has in the target raw data so if the image "starts" with "white", "yellow", "pink" then "white" is the background (0), "pink" is 1 and "yellow" is 2 the program detects the number of colors in the first line. In the explained case you have three colors, so 2 bit per pixels are needed in the target data(you could add a fourth color which still would fit into 2 bits per pixels) the palette is only for the pixel value assignment. The color values itself are not part of the output or translated into a "best-fit" of the Atari palettte! depending on the palette size the converter automatically produces 1,2,3 or 4 bit(s) per pixel target raw data. 3 bits/8 colors don't make much sense as the target bytes have two spare bits then. The 4 bit per color case is more interesting for the GTIA modes (untested)! output data in the source image is detected by frames which are not the background color - any other color will do (no need to be part of the palette). The user data is inside of a frame, having a one pixel margin to it. colors in the user data which are not part of the palette are ignored (-> background) You can have as many frames in a single image as you want and position the frames freely in the source image. The detection of frames is from top to bottom, left to right. Raw data of the frames is created in files consisting of the source filename and an enumeration. (test.png -> test001.spr test002.spr ...) Every line is padded to a full byte the option "-v" before the filename will output info about the conversion process (try it out!) the option "-h" before the filename puts the width in bytes, width in pixels and height in pixels in front of the produced raw data (a byte each) dimension of frames greater than 8 bit (255) are unsupported! the dimension of the source file is not restricted. You can produce the images in any size and with any tool you like (f.e. "GrafX2" if you like to have the 2:1 aspect ratio of pixels during edit) even the bitmap output of G2F makes sense! raw data to source code conversion is not a task of this tool! Please use xxd or other tools for this step! (But of course the the raw data is suitable for an ".incbin" in assembly code!) The archive contains this small 2 bit per pixel sample image: Don't hesitate to report bugs. img2sprites.exe.zip
  14. Ok, I see. You could produce the images with "Atari Graphics Studio" http://madteam.atari8.info/uzytki/ags.7z and bribe TeBe that he allows to change the size for the MIC format - which seems currently tied to the static 160x192 pixels... ...or you "filter/cut-out" the MIC data produced by the studio (read some bytes, skip some etc. - even something in TB-XL would work). Or you bribe me to create something more convenient for the command line, like "PNG in -> multiple 2-bit graphics which are surrounded by a frame of whatever size out"...
  • Create New...