Jump to content

VladR

Members
  • Content Count

    1,677
  • Joined

Community Reputation

1,080 Excellent

About VladR

  • Rank
    Stargunner

Profile Information

  • Gender
    Male
  • Location
    Montana

Recent Profile Visitors

8,486 profile views
  1. For Gourard, I haven't examined the frames in YT vid, but can VBXE's Blitter interpolate shades within a scanline (e.g. you would just provide start/end value) or is the color fixed across full scanline ? For normals, you use 1 byte per x,y,z, I presume ?
  2. Nice ! Is it running in 320x240 ? I presume you use VBXE just to draw the scanlines, right ? You do use tables for math, though - right ?
  3. Thanks ! That's the file I was looking for. I'm confused why would it take more than 1 scanline to stabilize via WSYNC ? Meaning, you must do DLI with WSYNC on first several scanlines (not just one?), otherwise there's still jitter ? Or you mean something else ? So, you tried it on CRT TV ? You mean it doesn't flicker as bad as some demos did 30 years ago ? Because that's the only reference point I got (for flickering). Here's my understanding: No Flicker modes: RGBY.4x4 : 4 Hues, 4 Brightness: Bitmap mode RGBY.4x6 : 4 Hues, 6 Brightness: Character mode Flicker modes: (Hues*2), (Brightness*2 - 1) RGBY.8x7F : 8 Hues, 7 Brightness: Bitmap mode RGBY.8x11F : 8 Hues, 11 Brightness: Character mode You can only select from base 128 colors (the values you POKE into color registers). But, once blending happens, I believe it creates new color space due to the nature of the blending process (chroma:hue is subsampled also vertically on PAL) - hence you should get much more than 128 colors, as at that point you are not limited by ANTIC's capabilities, but rather by the PAL color format (the vertical subsampling of chroma). That would make a great experiment - to compare results by color bleeding vs the standard 128 color palette! I'd love to see that !
  4. Man, I'm soooo glad I asked that question about your picture! No way I could have expected it would result in so much information on kernels! Thanks a ton for sharing this knowledge. My deepest respect!
  5. Wait, why would you need the current scanline and CMP/BNE ? Isn't the whole purpose of kernel to have a code for each and every scanline of the screen? Meaning for 160x192 bitmap mode you have 192 batches of 5-6 LDA/Sta (and wsync). Is there perhaps some reason this approach doesn't work in practice? As for the 60 cycles - yeah I forgot about PMG. That's at least 5 or more cycles lost. But I thought you are racing the beam here, hence majority of register changes are for current scanline. I presume your tool on PC has some safety threshold range for each change that you painstakingly discovered while debugging on Altirra - e.g. those 2 color clocks. Otherwise, there wouldn't be time to do the 5-6 changes while the beam jumps from end of current scanline to the start of the next one. As for the kernel debugging on Atari, I once tried it - as an attempt to improve the DLIs - about 3 decades ago and after half day of fighting had only 8 scanlines to show for it. Then I realized my sanity is more important
  6. How would you stabilize the kernel without DLI on the very first line via waiting ? Waiting after what exactly ? vblank ? Would that be remotely precise ? We need a starting Antic's reference point. DLI on first blank line seems easiest and safest, no ? Thinking about it, kernel now seems easier (and more useable) to me than a DLI (for non-game purposes, that is). You get at least 6 register changes per scanline and I'm pretty sure that with careful positioning of scene elements, you could get away with WSYNC completely by avoiding the adjusted colors in the jitter area (hence no visible external jitter). But, the image must have vertical zones, unfortunately. Let's do some break-down. 1 Horizontal scanline is worth 114 cycles. 40c goes towards Antic reading the FrameBuffer data (say, for a 160x192 mode) 9c goes towards Refresh (if I recall correctly) 1c is lost Anything I forgot ? Can't seem to find that detailed Antic's cycle breakdown on my computer right now... That's about 50c per scanline, so theoretically - within a kernel - in a noncharacter mode - one should have ~64 (114-50) cycles, right ? That's 10 pairs of LDA/STA without WSYNC. Of course, this presumes you don't do any of that manually, but have the converter do all the heavy lifting, automatically. Doing that manually would be sheer lunacy
  7. True - there's no interrupt servicing, no registers push/pop and this way you should be able to reuse registers from previous scanline, as there's no CPU main code running anyway (the kernel itself is the main CPU code). So, in the kernel coding, did you find the timing more predictable than with DLIs ? That's great to hear ! Thanks ! I totally forgot how bad the character processing is in Antic in terms of CPU consumption. WSYNC. It still pulls down the RDY line of 6502, halting it every scanline for some cycles. Those cycles could be used for additional color/PMG register changes. Now, unlike DLI, in theory, there should be less cycles butchered in the kernel than DLI. But perhaps without WSYNC you could 2 more color registers on average every 3-4 scanlines ? That would add up to additional colors (and, of course, complications in image processing ) But, more likely, when you iterate over hundreds of images, you will notice certain color patterns - certain combinations of hues and colors look better than others. So, basically, just more experience with the process. Can you share how many register changes can you do in a kernel (compared to classic DLI) per scanline ? I presume 5-7 should be possible without the DLI overhead ?
  8. That is absolutely insane that you can get away with WSYNC butchering the CPU yet still get this kind of quality ! WTF ?!? I would never in a million years believe this quality could be possible without precise cycle counting and without WSYNC. So, each scanline's kernel is just few simple LDA/STAs for color registers ended with STA WSYNC then ?!? Which means, that this can still be pushed further How exactly are badlines affecting this ? Doesn't WSYNC help with that or am I missing something about the nature of badlines ?
  9. Wow, just wow ! This is some incredible work. It absolutely deserves its separate thread!!! Looks like you explored the hue blending to the max then ? Or do you think there is still some more ground to cover ? How exactly do you handle the end-of-line jitter in your kernel ? Or is that why the many colors are somewhat distant from the screen edges as this way if one color change bleeds from end of previous scanline, it's hidden - correct ? I presume you generate the kernel automatically through your toolset ? Surely you don't write kernel manually for each picture ?
  10. Wait, you mean you disassembled the game executable and hacked it in hexa editor to remove the calls to those functions ? I now stand corrected and understand I should have added Stage 5 to my Cutscene Enjoyment Phases:
  11. I never saw Rasta's output on real TV, so can't really judge it, but I believe Gunstar does that often and if I recall correctly, he always says that output on real TV is much better than what we see here in the thread, so I'll take his word for it. But 3 meters distance to enjoy the picture ? Damn, that would be brutal You just reminded me of some flickering demos I saw as a kid, and since I grew up in PAL land, I still recall how badly sensitive I was to the flicker at that time. I'm not the guy to complain of headaches, but man - that stuff was painful after 2 minutes I'm absolutely sure I couldn't handle it today. God Bless LCD
  12. Matter of fact, yes - I used to load up some games just for splash screens and main screen, as the game itself was boring Then again, as a coder myself, I'm partial to the demoscene, so there's an obvious bias towards enjoyment of non-interactive content Of course, from a pure gamer standpoint, yeah - the cutscenes go through the following stages: 1. Wow, that's so cool. 2. Alright, alright, alright - I saw that already 3. WTF ?!? No Escaping this BS ? 4. AAAAAAAAAARGH #$!&& !!!!
  13. Ouch Anyway, it's still an amazing piece of work. Would have to see the real thing, though. Video can't really reproduce the flicker that you see in real life...
  14. Did you never get excited as a kid about a beautiful loading screen ? To this day, I still recall collecting my jaw from the floor, when Lucasfilm logo popped up on my Atari when loading Fractalus. That was more than 3 decades ago. For me personally, both the Loading screen and Main screen are an intrinsic part of the Atari's charm No 3DFX or nVidia GTX:1024 ever came close
×
×
  • Create New...