Jump to content

NRV

Members
  • Content Count

    437
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by NRV

  1. Not that I remember.. anyway it's not easy to know if they are really voxels just looking at the demo maybe some parts of "The Shrine" ? (well, I don't think so after seeing it again) is there any in the c64?
  2. should not.. assuming that it uses a VBI and it does not take too much time.. best way is just to test it
  3. but who would be answering that 20 posts? ... oh wait... haha I know that feeling.. hmmm from a friend, you know NRV
  4. Hey andym00! thanx for the previous answer. I know what we can do with the a8, I was asking just for curiosity, maybe there was an algorithm that could be interesting or useful in some special cases Just to remember some of the "enlightenment" reached in some parts of this thread: Good things from the c64: (from what I know) - the Sid ("only" 3 voices, but nice and easy to setup sounds) - the 8 "real hardware" sprites, colorful, with good resolution, can be multiplexed vertically and only need to change one address to move up/down and to be animated - the 320 pixels X-resolution with lot of colors, nice for dithering - the "let's scroll one 1 pixel" and "let's move the sprite 1 pixel" in a 320 pixels resolution - the 256 chars per font - the "colors per resolution per line" ratio is good - good system design compromises, overall + when it counted: the price + lots of "modern" games and a bigger "scene" Good things from the a8: - the palette (128 colors most of the time, 16 hues with 8 shades) - the GTIA modes (the "16 shades from one color" mode, that let you get 256 colors) - the scrolling system (is easy to scroll in all directions.. also you can have different windows, scrolling in different directions) - the 3 playfield width modes (32, 40 and 48 chars.. easy overscan) - the display list and all the graphic modes that you can mix (some of then aren't that useful, but is nice to have the options available) - the interruption system (NMI's and IRQ's) and WSYNC - the DLI's (that let you change lots of things "vertically" speaking: colors, font, scrolling, player's position and size.. to overcome some of the limitations of the system) - the POKEY for 4 voices and sound effects (the "Instrumentarium" song for example) - using the sprites as overlays to add more color (but at the cost of some planning and head scratching) - is nice to be able to "replicate" a sprite horizontally, but this is mostly for static screens, demos, puzzle games or very simple games (you lose too much cpu time) - is nice to have the "collision detection" options for the sprites, but they don't get used that much - the processor "speed" (if you want more speed you can disable the screen, or have a display mode with big pixels that don't use too much cycles, useful for 3d games and demos) - the "chroma effect" in PAL, that lets you have a 256 solid color mode (the problem is that the colors are a little darker and you lose half the vertical resolution.. and it doesn't look good in NTSC) - the just discovered "RIM" mode (Rybags interlaced mode ), that lets you "duplicate" the vertical resolution, but at "half" the frame rate + I suppose the peripherals and modern hardware advances, by I'm mostly a software guy.. + Numen, DChessboard, Alternate Reality, BallBlazer, Eidolon, Encounter, RoF, Koronis Rift, Space Harrier and.. Bad things from the a8: - "the colors per resolution per line" ratio is low - the sprite system (the number, the width, and not multicolor in the real sense.. they are like software sprites when moving vertically and when doing animations, you need to copy memory in most cases) I think that the sweet spot for c64 are the games that use a lot of colorful sprites, like shooters and platformers, and the arcade games from the 80's. Also the Sid in itself For the a8 that should be something like the weak spot.. you can only do good ports of some of them, the others lose too much. The a8 "shines" mostly with 3d games (maybe also with isometric games) and with 2d games that have the "verticality" and the architecture of the machine in mind. (for popmilo) I think that nowadays you should design your game thinking on the limits of the machine, more than just make a port from another design. For example this screen could be a good compromise for an action platformer in the a8: It's a normal Antic4 char screen, 5 colors per line, plus player3 and missile3 used to add a 2 more colors, as "underlays" (the pipes). There are always black and white colors to add detail, and two colors that can be used for the background. There is a DLI every 8 scan lines (in almost every char line) to add more color and change the P/M position. With this you still have the 3 other players and missiles, that could be used to add color for the (human) player and some enemies. You will need to use software sprites over some area of the charset, losing like 40 chars (according to the number, size and movement of the enemies), but you can also change fonts with the DLI's. Adding horizontal scrolling is easy, but the vertical scrolling could be tricky, because you need to update the P/M (easy if they are mostly squares) and the DLI's position (but it can be done). another example of a colorful screen in the vertical axis (using just two color registers): By the way popmilo, our "windmills" are some of the best in the world, you don't have any hope to win against them regards
  5. Two questions.. can you do those same techniques in an Atari? (and if you don't know, can you point to a webpage with info, or describe them a little ) and.. do you have a limit to the scroll speed that you can use with those techniques? something like "1 character per frame"? (or maybe you only need more setup time if you go over "that" limit) thanx NRV
  6. Yep, that was what I did, you need to use the "hardware" vectors, if not there is no enough time.. I should test it in real hardware, because if the IRQ's doesn't start at the same point, in the emulation and in a real computer, this method could not work.. Anyways, you can also do it with DLI's (at least the GTIA 9+11 mode), but only for narrow mode and with a "high" cost I needed to use the NMI hardware vector AND lost the "x" index (i cannot use it in the main code, only for the interruption code), because the first instruction of the interruption is always "STX PRIOR".. with this you can be sure that PRIOR has the correct value before the start of the line (and don't need to use WSYNC) This is the code for the "one DLI per scanline" method. You can do also one DLI every two scanlines, I never did because I started using IRQ's.. I wanted my "X" back ;---------------------------------------- ; display list interrupt 1 code ;---------------------------------------- DLI1_address stx PRIOR ldx #PRV_GTIA_9 ;---------------------------------------- sta m_dliSaveA lda #<DLI2_address sta NMIH_VECTOR lda m_dliSaveA rti ;---------------------------------------- ; display list interrupt 2 code ;---------------------------------------- DLI2_address stx PRIOR ldx #PRV_GTIA_11 ;---------------------------------------- sta m_dliSaveA lda #<DLI1_address sta NMIH_VECTOR dec m_dliLineCounter beq DLI2_last_line lda m_dliSaveA rti ;---------------------------------------- DLI2_last_line lda #MAX_DLI_LINE_CTD sta m_dliLineCounter ; reset last line counter lda #0 ; reset PRIOR to 0 for the rest of the screen sta WSYNC sta PRIOR lda m_dliSaveA rti NRV
  7. Not really.. just the 50% or less.. I have done this with IRQ's but I suppose you can do it with DLI's also.. For the GTIA 9+11 mode you can set an IRQ to happen every two scanlines, at the very start of the interruption you set the PRIOR value for mode 11, then waste some cycles and when the scan is outside the screen you set PRIOR to the value for mode 9, then exit your interruption.. so you don't need to do anything in the next scanline I did this for narrow mode and I think I can do it for normal width, but not for the wide mode, because there are cases when the interruption starts too late Also I have tested this only in the emulator Regards NRV
  8. Envision 8bits? press the "W" to "write data statements" and select MAC65 format.. I don't remember if you can save the font and the map to different files.. Envision PC? you use "E" to export the font and "S" to save a binary map if you already have the data in decimal format I think that you should be able to use it in Atasm.. if you were using MADS you could just include the binary file NRV
  9. what are you saying? that you don't know the rest? NRV (we could make some kind of contest: program a game with just this instructions..)
  10. ascrnet, that code DOES: X = $F A = Y = $3 you must be doing something wrong after that (or there is a problem with the assembler..) NRV
  11. Can you do this mode with IRQ's ? so to not waste cycles with WSYNC.. I have done the GTIA 9 + 11 mode with IRQ's in 15KHz and with AUDF1 = 0 (counting one scan line), but I don't know if you can sync the IRQ's to the specific point needed to change the VSCROL register (STA WSYNC, NOP, STA VSCROL) NRV
  12. yes, for the "23 in the same line" thing you should do something like: if just for static pictures you could always do some kind of "line kernel", at the price of most of the machine cycles, for every scan line involved.. NRV
  13. Great work! any chance to support the MADS assembler in the future? or maybe is there a way to configure it ourselves? NRV
  14. ah, sorry, I was talking about setting GTIA 9, 10 or 11 over graphic mode 4.. in other words gr.4 with PRIOR = 64, 128 or 192 NRV
  15. well, there is no chunky mode but you can always do (3d?) games assuming a resolution of 80x192 and writing the whole byte all the time maybe a stupid question, but.. do graphics 4 mode (2 colors, 80x48) works with PRIOR values for GTIA? (or any other mode that is not gr.8?) NRV (I suppose that the answer is "not really.. weird things happen", because if not the VSCROL trick is not that useful)
  16. be thankful that I don't used "page flipping" ! NRV
  17. so we have a gtia pixel with a 8:1 ratio now? and the PAL trick of "interlacing" gtia 11 and 9 lines to get 256 colors works in some way? NRV
  18. no, the "shifting" is just vertical dithering.. is a plain gr.15 (antic 14) screen with 192 different scan lines NRV
  19. Here.. I like to reuse this picture the vertical bars are the players 0/1 , 2/3, and the missiles 0/1, 2/3 the horizontal bars are the colors in registers 708, 709, 710 and 711 the graphic mode is Antic 4 using the fifth color (the green line).. no DLI's you can count 23 colors, including the black: - 5 for the playfield - 6 for the players - 12 for the combination between players and the playfield NRV (well, you can do more, but things get a little more complicated..) (this was for "that" other thread, but I'm taking too much time and that thread is gone for good )
  20. but Vitoco.. that version of yours have more than 20 years!! and from what I remember it was all grey Regards NRV
  21. Nice! thanks.. from what I get you put values from 1 to 255 in vscrol (the first time) and then from 64 to 255 in every frame.. could that really work in a real machine?!? regards NRV (well if what Rybags says is correct I suppose you can just rotate the values between 0 and 15 and you would get the same results..)
  22. Yes it is. Nice one, didn't know it's not limited to 16 scanlines. 105 free cycles for the CPU on pencils body is great. hey MaPa! how do you use it for more than 16 scanlines? only vscrol or you need to use more LMS's in the display list? could you post your code? I'm doing my own "pixelmark" version, but I don't want to use the vscrol trick.. regards NRV
  23. sure, just unzip and move the .obx file over the running emulator window.. I do this over Atari800Win Plus 4.0 and it works NRV (hmm machine type XL/XE, 64k, NTSC, basic off.. should work)
  24. Yes.. that's real here (with some more graphics): tdemo.zip only restriction is that you can use all the colors only in the play area.. the original thread: http://www.atariage.com/forums/index.php?s...=136584&hl= NRV
×
×
  • Create New...