drpeter
-
Posts
744 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Everything posted by drpeter
-
High Cupgill Pennines, east Cumbria, UK. Area in view: https://osmaps.ordnancesurvey.co.uk/54.60925,-2.44089,14, looking SW 36 colours. drpeter_High_Cupgill.xex
-
This was posted in June on the Facebook page: Retro Cartridge update: Atari "Director's Cut": This will be the completion of the 48k 1983 version in my vision. I'm personally working on the Director's Cut Boss challenges along with other new features right now. These features will first be seen on the Atari 800 cartridge but will make it to the cross-platform version. We'd be interested in hearing from publishers who might be interested in this product too. I'll share some more media on this soon. Please feel free to DM here or email support@normaldistribution.com -Thanks! -
Bjorn Again Björn Ulvaeus- as he was then, and as he is now... 22 colours. drpeter_Bjorn.xex 49 colours. drpeter_BjornAgain.xex
-
According to this, 288 IS the supposed maximum, having deducted the minimum 25 scanlines required for VSYNC in the PAL specification. This supposed upper limit is therefore not to do with 'TV safe' overscan, which is a different issue and usually considered to be well below 288 displayed lines for PAL. Websites discussing the C64 overscan area appear to suggest that the VIC II generates 284 scanlines between VSYNC periods.
-
Yeah, but the question was not so much how does the C64 put graphics in the upper & lower borders, but how does it hope to display borders beyond the PAL specification of 288 vertical (non-interlaced) scanlines maximum? On some sort of monitor output? I know very little about the C64...
-
The youtube video capture of the source demo shows a static image with 8 scanlines missing from the top & 13 from the bottom, i.e. 272 visible.
-
This isn't a bad effort, for RastaConverter. Cropped to 160x240. drpeter_RainyStreet.xex
-
I note this is a 320x293 pixel image. I think that's more scanlines than PAL can display, even with zero vertical overscan! (288 per frame, the remaining 'inactive scanlines' occur during vertical blank)... How is this image displayed on the C64, I wonder?
-
C64 has black, white and 3 grays. As you can see by looking closely at this image.
-
I have messaged you.
-
Wild Pony Dartmoor pony. 37 colours. drpeter_WildPony.xex
-
ABBAtar Agnetha Fältskog, in her recent virtual reincarnation for the ABBA Voyage stage show. 26 colours. drpeter_ABBAtar_Agnetha.xex
-
According to Jay Miner, it was in part what inspired the blitter features. https://pipiscrew.com/amiga/
-
Well, that was kind of different, being a genre the designer had in mind from the start rather than a specific game that changed design substantially mid-project. In similar vein, the original conception of the Atari 8-bit graphic chipset included the idea that it would have 4 joystick ports, 4 player graphics and 4 missile graphics in order to be able to implement 4-player 'Tank' type games.
-
Please do not try to make this thread a discussion of critical opinion. It will lead nowhere and discourage posting. If you don't like it- please keep quiet, move on and post something you like.
-
A further manifestation of RastaConverter's player repositioning bug I've recently stumbled across another consequence of the player repositioning bug in RastaConverter- one that seems to occur less commonly, but also is obvious when you think about it. It's the reverse of the usual situation, the one where RastaConverter assumes a repositioned player will be displayed in its new position on the same line but actually it is not- allowing pixels from COLBAK or a player with lower priority to unintentionally 'show through' instead. This 'new' type of error can occur when RastaConverter repositions a player after it has already triggered but not yet displayed at its current HPOS (i.e. during the 5-6 colour-clock delay between these 2 events). RastaConverter is not aware the player has already triggered, and that it will now therefore be displayed at its existing 'old' HPOS position regardless. It assumes that the repositioned player will NOT be displayed at its 'old' HPOS, thereby allowing COLBAK or lower priority players to appear, but in fact any such pixels end up obscured by the player displaying at its 'old' position regardless of the repositioning. @Sheddy will be including this new observation in the annotations of disassembled Rastaconverter .xex files output by Rastaslide (output.png.rp). In the meantime, I have updated my tutorial on the subject, again. Tutorial Walkthrough_Ver4.pdf
-
Fascinating. I wondered in another thread whether the 400 was the only example of a hardware design being substantially changed in order to facilitate the playing of a particular game (in that case Star Raiders). It seems not!
-
In some ways, you could argue, aspects of the 800's design were a reaction to the Apple II, being a (perhaps over-elaborate) attempt to move from a 'techy-oriented' to a 'consumer-oriented' product. This is shown most clearly in the unique OS/RAM cartridge slots, designed so that both could be changed without even opening the main case never mind taking the product back to the dealer. This was probably overkill- expanding the RAM through a dealer- as many 400 owners did- wasn't an issue to most and replacement OS cartridges were never issued. Ironic maybe, given the way Apple later moved down the path of 'do it our way' proprietary closed systems, closer to the Atari design philosophy, while IBM clones went on to inherit the open architecture approach.
-
Badgers 34 colours. drpeter_Badgers.xex
-
No way! This is incredible. ? You only get 160x192x45 colours sort of, unfortunately, there are significant restrictions in both how the pixels and the colours can be formatted. In a similar sense, but in a different way, that you can get 192x240 x 128 colours, with restrictions, in wide playfield mode of ANTIC mode E (Graphics 15) using display list interrupts or a screen kernel.
-
Hi, Sorry, I don't exactly understand which files you are asking for. Please list. Maybe reply using messenger, to avoid starting a long conversation in the thread.
-
@Mauro Rodriguez Best wishes for a speedy recovery.
-
I'm sure you're right. I was being slightly tongue-in-cheek.
-
This is a very impressive tool, but as I understand it, it facilitates making 'point & click' style graphic games, not illustrated parser-based text adventures, which unfortunately is what I would be interested in.
-
Agree, but as far as I know we lack a good authoring tool that could compile such a game to an A8-compatible format. Without such an authoring tool, the work involved in writing a text adventure/work of interactive fiction is increased by an order of magnitude and the quality of the end product diminished likewise.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord