Jump to content

NRV

Members
  • Content Count

    436
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by NRV


  1. After all the experiments from Vinscool, Synthpopalooza and other people, I would say that supporting custom note tables (3) and providing fine control over all the Pokey values per frame (7), when needed, are the most important.

     

    You can forget about number 6. It was that sometimes, some note tables or instruments, need to be used in specific channels. But you can give total freedom to the user in the end, there is no need to check everything.

    • Like 1
    • Thanks 1

  2. 1 hour ago, ascrnet said:

    Hi all,

     

    I am passing a program from MAC65 to MADS, but I did not understand what the equivalent of the following lines is :

    BASE = $5000
    
    ; MAC65
    SETVEC = *-BASE
    BUFFLEN = *+1
    ERRNUM * = *+24
    
     * = *+49
      .SB +$80," START "

    regards

     

    I would try with something like:

     

    BASE = $5000

    SETVEC = *-BASE

    BUFFLEN = *+1

    ERRNUM

       org *+24

       org *+49

       .sb +128, " START "

     

    (untested!)

     

    • Thanks 1

  3. 5 hours ago, vitoco said:

    I liked Bopotron (A.N.A.L.O.G. #24, Nov 1984) very much, because in the same magazine it was also published a construction set (another type-in program) to create and add custom levels. I designed some of them...

     

    You made me remember that I typed that one, almost finished it, but lost it to the Atari Basic's lock up bug (could not save it 😕).

    Never tried again x)

     

    Probably the ones I played most:

    - Zurk: http://www.atarimania.com/game-atari-400-800-xl-xe-zurk_5952.html?version=5952

    - Kooky's Quest: http://www.atarimania.com/game-atari-400-800-xl-xe-kooky-s-quest_2834.html?version=2834

    - Avalanche: http://www.atarimania.com/game-atari-400-800-xl-xe-avalanche_442.html?version=442

    - Spy Plane: http://www.atarimania.com/game-atari-400-800-xl-xe-spy-plane_4952.html?version=4952

     

    Maybe Avalanche could interest you.. is a QBert clone in machine language, from Analog.

     

    • Like 2

  4. 23 hours ago, SlidellMan said:

    Just played it on JS7800, and you just may have made the best 8-Bit home port of Arkanoid. Maybe you could port more Taito arcade titles such as Raimais (You may have to include the cutscenes from the Japanese version), Darius, Legend of Kage, Bubble Bobble, Space Dungeon, or Exzisus?

    There is already an A8 version of Raimais, so there is code done if you need it, but probably if there is a popular vote Bubble Bobble would win x)

     

    (and the graphics for the 7800 are already done in this thread: )

     

    • Like 2

  5. On 8/22/2020 at 5:14 PM, ivop said:

    Idea for a multijoy game. Five persons. One person controls Pac-Man. Four people control Blinky, Pinky, Inky and Clyde. After death, Round-robin the players one, two or three full rounds and count the points gathered by each player. Perhaps extra points for being the ghost that catches Pac-Man. For less than five players, Clyde(Inky(Pinky)) could also be computer controlled.

    https://en.wikipedia.org/wiki/Pac-Man_Vs

     

    • Like 1

  6. 4 hours ago, MrFish said:

    The fix for this is easy. You simply test for <SELECT> to be pressed, then you test for <SELECT> to be released. That's it.

    As a general programming advice I prefer the other option, detecting the "just pressed" event, so a detection of a "key not pressed", followed by a detection of "key pressed".

    That way you know that no other application can mess with yours.

    Also, detecting "just pressed" feels more responsive than detecting "just released", from the user's perspective.

     

    But I understand that this doesn't protect you from messing with the next application :D

     

    • Thanks 1

  7. 7 hours ago, mksmith said:

    The ball movement/collision really gets me frustrated at times

    What method do you use?

    When I did my pseudo clone I moved all balls by steps equal or lower than one pixel, many times per frame, checking if they cross over brick limits.

    With this there is no problem with the collisions (even if you hit more than one brick in the same frame), but the problem is that a higher speeds (and with more active balls) the processing cost is also higher.

    So I don't know if this method will work well with the 7800.

    Well.. probably there are ways to optimize this, like doing the fine steps only if we are moving through a zone with bricks on it.. but I never explored this solution.

     

     

    • Like 1

  8. On 7/24/2020 at 4:49 PM, Philsan said:

    Canyon Bomber is an arcade game made by Atari in 1977:

    1288004831_CanyonBomberArcade.png.295dbc55839fba2e23efc528914a0b49.png

     

     

    Is kind of funny that this can done almost equal (or better) in the A8 (G0, P/M's for the white "underlay" color, narrow playfield).. and the arcade uses a 6502 clocked at 756 KHz.

     

    How much do you like the original? :D

     

    • Like 3
    • Thanks 1

  9. Not trying to influence your opinion, I think both options are valid, but I just wanted to add a vote for some "mild" randomness.

    Probably one of the extreme examples for this is something like Spelunky (or Rogue Legacy for metroidvanias), and for sure that have some epic speed runs :)

    In my case, when I do any type of game I end testing it so much, that I feel forced to add some kind of randomization, so it still feels fun down the way.

    Without changing the order of rooms, I have experimented with changing the starting direction of the enemies, changing slightly the speed of some enemies and obstacles,

    adding a small random delay to the start of some periodic events, all with the intention that the player don't only memorize every pattern, but has to adapt to the small changes.

    Anyway, whatever you do is going to be a great game 😛

     

    Saludos vecino.

     

    • Like 3

  10. 1 hour ago, Wilheim said:

    A.N.A.L.O.G. has a maze generator as well, in the game Motorcycle Maze Rider, created by Charles Bachand.

    Ouch.. that fired some neurons that were sleeping for more than 30 years x)

    The vector line maze.. the sound..

    It was in the Analog Compendium.


  11. If the macros provided by mads are not enough for your case you can do your own.

    But you need to decide first where you want to put the results (A, X or Y, or some memory addresses).

    Also if you want to support negative numbers and how you handle the cases where there is overflow (adding two bytes could give you a word result, for example).

     

    Anyway the syntax would be something like:

     

    .macro Add
    
    .if [:1 < 256] .and [:2 < 256]
    // code to add two bytes..
    
    .elseif [:1 < 256] .and [:2 > 255]
    // code to add one byte and a word..
    
    .elseif [:1 > 255] .and [:2 < 256]
    // code to add one word and a byte..
    
    .else
    // code to add two words..
    
    .endif
    
    .endm

     

     


  12. More than that, if you have more than one software sprite:

    - first "erase" all previous/old sprites in the screen

    - then draw all new sprites

    ..repeat

     

    Erasing means restoring the background and it can be done in different ways, for example:

    - if you background is empty, you just put 0's in the old sprite position.

    - or you could have a copy of the background in memory and just copy the area touched by the sprite from there.

    - or use some other logic to restore the background, like when using background "tiles"..

     

    Drawing can also be done in different ways, some of them faster but prone to more visual artifacts:

    - just storing the sprite data on the screen without masking or caring for the sprite "borders" against the background.

    - doing an OR or XOR/EOR of the sprite bytes against the background.

    - doing the "proper" method of having a sprite mask (different than the sprite data) to AND against the background (basically cutting a hole with the shape of the sprite in the background),

    and then ORing the sprite data against the background.

     

    Then there is the problem with rotating the sprite bits inside a byte, because the graphic modes use 8, 4 or 2 pixels per byte.

    This can be done in real time (slow) or having the rotations pre-calculated in memory (faster, but using a lot more memory).

     

    All this is for graphic modes. Char based software sprites are a little more complex.

    • Like 2

  13. 8 hours ago, popmilo said:

    May we ask what kind of software is that ?
    And that language you mentioned is inside that software too ?

     

    8 hours ago, Jetboot Jack said:

    Google is your friend...

     

    https://atari.miribilist.com/envision/

     

    Yep, that's the original PC port.

    There was another version with improvements, but the links seem to be broken:

     

    https://code.google.com/archive/p/envisionpc-reborn/

    http://atarionline.pl/forum/comments.php?DiscussionID=1220&page=3

     

    Here is the version that I have:

    epcr.zip

     

    The "language" is something that I did for Project M because I was low on memory for more maps x).

    That second map (27 x 20 tiles, should use 540 bytes) look like this in code:

    TabMazeCode2
    	.byte MCMD_BLOCK, 28, 0,0, 32,45		; full level
    
    	.byte MCMD_REPEAT_IN_BLOCK, 5,2, 4,4	; 5x2 empty rooms of 3x3
    	.byte MCMD_BLOCK, 0, 6,12, 3,3
    	.byte MCMD_REPEAT_END
    
    	.byte MCMD_BLOCK_ARRAY, 9, 0			; 9 empty space blocks
    	.byte 2,1, 9,9
    	.byte 12,3, 7,7
    	.byte 24,3, 3,3
    	.byte 11,4, 1,2
    	.byte 19,7, 2,1
    	.byte 21,4, 1,4
    	.byte 22,4, 2,1
    	.byte 15,10, 1,6
    	.byte 17,17, 5,1
    
    	.byte MCMD_BLOCK, 28, 4,3, 5,5		; normal brick block
    	.byte MCMD_BLOCK, 22, 14,4, 3,2		; purple brick block
    	.byte MCMD_BLOCK, 21, 14,7, 3,2		; red brick block
    
    	.byte MCMD_POINT_ARRAY, 3, 11			; yellow metal
    	.byte 6,4, 7,5, 5,17
    	.byte MCMD_POINT_ARRAY, 4, 14			; green metal
    	.byte 6,0, 11,7, 13,17, 21,13
    	.byte MCMD_POINT_ARRAY, 8, 0			; empty space
    	.byte 9,17, 11,15, 13,13, 19,15, 4,5, 5,5, 6,6, 6,7
    
    	.byte MCMD_POINT, 1, 6,5				; key
    	.byte MCMD_POINT, 4, 6,17			; gold cup
    	.byte MCMD_POINT, 5, 26,4			; teleporter
    	.byte MCMD_POINT, 47, 27,4			; animated texture
    
    
    	.byte MCMD_END

    Obviously, you need to add the memory used by the code to "draw" those commands, so in the end I don't know if I ended using less memory x) (there are two more maps like this one).

     

     

     

    • Like 2

  14. 6 hours ago, tabar said:

    i realize it is early in development, but how is the level data stored and can it be edited? i enjoy creating levels for doom( 1, 2, hexen, heretic, wolf3d).

    Well, I wouldn't call it exactly "early" :)

    The start of this thread is from 2010 and the map is the same as my last experiment:

     

    mapf1.thumb.png.8813c7a6744138ff7513f851182b6213.png

     

    This was done in Envision PC.

     

    The 3 maps after this are done with a kind of "language" that draw the map in memory, so they use less space than the final size of the map.

    For example the next one:

     

    mapf2a.png.2f62c2d21e078c80a8da98f100df617e.png

     

    Basically the language let you draw square zones or lines of any type of tile, and also list of objects, if I remember correctly.

     

     

    For people talking about trading slanted borders of a column against vertical resolution.. I don't think it's a good trade off.

    Remember that you need both orientations for the slope (increasing or decreasing from left to right).

    That the slope can connect to the side chars, but also to the chars above or below them (because.. perspective).

    That you need more than the 32 different heights of a column, because for size 32 you still need some different columns, because the inside of the texture changes when you are nearer a wall.

    And the number of columns in a font is already very limited (128), so it would mean a very coarse vertical resolution in the end.

     

    I don't know if I read it well, but using more than one font per line is not useful for this technique.

    Assuming you can do it (is impossible in the bad lines and you are going to consume all the cpu in the char lines, for every hardware frame!) it doesn't help you,

    because you can need every possible column variation in any horizontal position of the screen (so they must be in every font used in a line).

     

    • Like 4

  15. Thanks for the feedback, everyone.

     

    11 hours ago, ilmenit said:

    Did you experiment with look of the enemies at that low horizontal resolution? Would they look acceptable in the distance?

    Not yet. I was hoping to have something that looked good with two players, using a GTIA like resolution (double width and double line for P/M's).

    What I know is that I would like to have the different sprite zoom levels in memory. I don't think that using a generic scaling routine is going to look good.

    The pilot running to your ship in Fractalus came to mind.. don't know if that is a good target x)

     

    10 hours ago, Rybags said:

    Re the game engine - I'm still of the opinion it's greatest use might be for an RPG type game.

    Wolf3D and Doom games are beyond practical for 8-bitters and realistically serve as a novel demo.

    A dungeon crawler, now that could be a classic.

    Hmm I think it can do both, with one or two enemies active at the same time, but probably my first experiments will be more "action" oriented.

     

    7 hours ago, R0ger said:

    Wouldn't it be better to simply use kernel code ? How many cycles can you save using those IRQs ?

    Uff.. I don't think so :)

    I don't say it cannot be done, but using IRQ's is a far easier solution.

    Remember that my "logical" frame can take any number of hardware frames (and we are not talking about an "integer" number of them).

    If trying to use something similar to a kernel, I would start the kernel code with a DLI, just at the start of the APAC zone, and would return at the end of it.

    Doing it like that would mean that the PRIOR changes use the less processing time possible, but then you need to do something useful the rest of the time (while still in the kernel).

    And I don't have a task that I can easily interleave with that job. Rendering sounds like a good candidate, but it would still be difficult.

    Playing music could fit, but I wouldn't want to do that with RMT.. it would have to be my own code.

     

    7 hours ago, emkay said:

    The scanlines would be less obvious, if the gaming screen was bigger.

    I don't think they would be less "visible", but if you are talking about the "sensation" that a bigger screen produce, sure.

    I didn't mention it, but Project X is the perfect candidate to use the full screen.

    Adding 8 more columns for raycasting would slowdown it, but maybe not that much, and increasing the height is kind of "free" with this renderer.

    Except for the cost of the extra IRQ's and the display list lines, of course.

     

    5 hours ago, CharlieChaplin said:

    (Gr. 10 RIP-mode with up to 160x240 resolution)

    RIP was the mode that used GTIA 10 and 9?. I would like to test it at some point, but I don't think that the displacement between both modes qualify as "160" width resolution :)

     

    3 hours ago, popmilo said:

    Am I the only one who wants to see xex file ? ;)

    Would you mind sharing details about that 64 bytes screen ?

     

    Awesome tech NRV! let's see another update in couple years ;)

     

    A couple of years sounds good 😛

    I didn't feel this test merited a xex file yet.. the same maze.. simple columns as objects.. so let me think about it x)

     

    About the mode.. is pretty simple in reality.

    Mirroring is not used, the different vertical gradient of colors should give up that away.

    Is like the idea from Irgendwer, but not for LMS lines. Instead is for columns of chars.

     

    It could be done with only 32 bytes. So let me start there..

    You have 16 lines of chars and every line has a different font (so I use 16K in fonts).

    But every line in the display list, points to the same 32 bytes of memory.

    So when I put a number in the first byte I automatically draw that whole column in the screen!

    Is like the idea of using different fonts for using char software based sprites, but taken to the extreme x)

     

    But as I said, you are very limited in the number of designs you can use for the walls. You need all zoom levels for every column in the fonts.

    In this case it would have been useful to have fonts with 256 chars.. but that also would mean needing 32K of memory!

     

    Finally, with 64 bytes I can have one version of a column for the top half of the screen and another for the bottom half.

    So I have more "design" options for the walls. I can mix and match different top and bottom parts.

     

    Also, I'm not using all of the font rows, so there is still space to use char based software sprites with this.

     

    • Like 7

  16. I had some time after the Raymaze thingy and I used it to test some ideas "accumulated" in my head, after all these years.

    So be warned, long post ahead, with raycasting ramblings..

     

    I had 3 things that I wanted to see working:
    - what I call the "line flicker" effect for APAC modes
    - an idea for a new (very fast) renderer, called Project X, that uses APAC over a char mode
    - and all the logic to have objects working

     

    APAC Line Flicker:

     

    The line flicker effect is basically having a normal screen in the "even" frames, and setting the screen one scanline down in the "odd" frames.
    So for an APAC mode, the GTIA 11 and 9 lines of one frame mix/merge with the GTIA 9 and 11 lines of the next frame.
    Then this is similar to interlace, but the idea is to reduce the dark lines product of using the GTIA 11 mode.

     

    Here.. a video is better.. (you need to set the quality to 720p50Hz to see it):

     

     

    In the middle of the video I activate the "frame blending" option in Altirra, so that's why the effect start looking "better".
    From what I understand some modern TV's do a similar effect.

     

    I'm a little undecided about this, but it could be an option. Probably I could give a final verdict if I see it running in real hardware.
    I think it would be a little better in NTSC also (30 Hz instead of 25 Hz).


    Implementing this with DLI's is trivial, but with IRQ's it was kind of a "side quest".
    First problem was that I was using one IRQ every two scanlines, to flip between GTIA 11 and 9 every line.
    Why?, because for 32 bytes mode lines, is faster to do a medium IRQ every two lines, than one small IRQ every line.
    Given that I was also going to implement this effect over a char mode, using one IRQ every two lines was "convenient", to skip the bad lines.

     

    But if you want to move your screen one scan line down, every "odd" frame, you will need to re sync the starting point of your IRQ's.
    That means touching SKCTL (15KHz clock) or STIMER (1.79MHz clock) every frame.
    And if you also want to play sounds or music, you don't want to write SKCTL or STIMER every frame, because they are going to sound wrong.
    I don't know if there is a way to do that.. maybe this is a question for phaeron :)

     

    In the end, I also needed to change the font every mode line, so with all those requeriments, the only solution was having one IRQ every line.
    Using the IRQ on channel 1, clocked to 1.79MHz, I can use the remaining 3 channels without any restriction (no need to force the music to 15KHz).
    Also you can sync the IRQ's to a point before the start of the badlines, so there is no conflict there (it still needs to be short).
    And you can move your screen one scan line down every odd frame, without the need to touch STIMER, just by moving the scan line of your DLI that init the IRQ's for that frame.

     

     

    Project X:

     

    The idea behind Project X was having a renderer with a processing cost near 0.. is that even possible?, without using all the memory?.
    Well.. yes. For starters one screen window uses 64 bytes, compared to the 4K per screen of Project M.
    So is kind of obvious that writing 64 bytes is a loooot faster than writing 4K (we are talking about the same screen resolution).
    I suppose this is a good example of the flexibility of the A8 to generate special "graphic" modes x)

     

    The big drawback of this mode is that you can only have very simple walls, so no complex textures.
    If you are smart you can have a good number of variations (more with a cartridge), but you have only a few number of different designs to use.
    The good thing is that they can be colorful, you win a nice and free depth cue effect, and you get back like 16K of ram (comparing it to Project M).
    Also, most of the processing time can be dedicated now to the "raycasting rays" part, and also.. objects experiments.

     

    Project M has a type of renderer that uses a block of around 14K for the scaling code (to scale up or down the textures).
    The scaling code points to a fixed 8K area in memory, where all the textures reside (and that would be one hell of a use for the banks of a cartridge).
    This is basically precompiled code, very fast, but still need to fill a 4K area for every logic frame.
    On the other side, Project X is the type of renderer that has all possible wall columns already scaled in memory, so it only needs to write 2 bytes to generate a
    final scaled wall column on screen (with background included).

     

    For this particular renderer it could be useful to use GTIA 10 instead of 11, to generate the color part of APAC, but I would need to see how that looks, because
    of the different offset of the GTA 10 pixels against the GTIA 9 pixels.

     

    px6.png.b12f8b9711a95c3c05ffd99280906404.pngpx8.png.0b670ca4264a022b902bdf5c27565c33.pngpx11.png.576ab1c9846f903f0a96d6d156eb1182.png

     

    Another advantage of Project X, is that it allows the camera/player to be closer to the walls, so is easier to move through doors.
    Also, the extra speed allowed me to increase the visual quality, using more precision on some of the raycasting data.

     


    Raycast Optimizations:

     

    After this, it was time to optimize the raycasting code.

     

    Now that the camera pivot is in the player position, there was a way to speed up a lot the camera rotations.
    It could have minor visual imperfections, but they are noticeable only if you are looking for them, so I tried it on.
    Then.. rotations were running at 54 fps in PAL ... yeah that's not an error :) (still NTSC was a little slower than 60).
    Because my frame rate was never that high and I use double buffering, I never needed a hard screen sync before.
    So it could happen that I render more than one logical frame per hardware frame.
    I added a "soft" kind of screen sync, so PAL don't go over 50 (softer than just waiting for a specific VCOUNT value, I wait
    for a VCOUNT "zone", so you can start rendering the next frame sooner, if the previous one was shorter than average, for example).

     

    After that, was the turn to improve all the raycasting that is done outside rotations.
    I had the idea, long ago, about interpolating most raycast info between 2 rays that were touching the same wall.
    The full idea means doing something like a binary search over the rays, and a general interpolation between any two rays.
    But there is a danger that doing all that could end up costing you too much time.
    So I decided to do a simplified version, that only check if ray N and ray N+2 touch the same wall, and then see if it can interpolate
    most of the data from ray N+1 (interpolation is also easier this way, with some specifics to the type of data you are interpolating).

     

    It was another good optimization. I would say in average 8 rays get interpolated (which is a lot faster than doing the raycast).
    So the speed up is similar to the one when you run Project M in the smaller window (starting the demo with SHIFT pressed).

     

    I can easily move these optimizations to Project M (fighting a little with ram distribution), so that's a low hanging fruit for the future.

     


    Objects:

     

    The implementation for this is another old idea. It was kind of surprising that it worked so easily and without major issues x)
    Basically, for every active object, I need to get the direction from the player, the distance and the screen size of the object.
    For every one of these I have a table that is accessed using the positive deltas between the camera position and the object position.
    Is little more complex, because there is also a "scale factor" involved, that is related to the distance between the camera and the object.

    If the object is closer to the player, then the tables provide more "resolution" for the data that they contain.

     

    The direction is transformed into a world angle index, that is later changed to a screen angle index, to see if an object is inside the screen.
    Then the distance is used to see if we need to clip some columns of the object, against walls that can be between the camera and the object.
    Finally the object should be rendered using the correct sprite frame, for an object of that size and with that orientation.
    This is different in the video, because for now I only draw columns of different width and size, and also change the color according to the distance.

     

    Right now the angle table uses 1K and I think it would look better with more resolution (that would mean 4K instead).
    The distance table uses 256 words (so 512 bytes), and it haves 7 bits of precision that I'm not using yet, but it works well enough.
    I was using a size table of 256 bytes, but in the end I don't need it, because objects also need the perpendicular distance to the camera
    (same correction as wall columns), so I'm using the same code used for the walls, to get this scale factor.

     

    In the video I implemented two "objects", one of them moving in a loop. They get activated when they are at a "visible" distance from the player
    (like 8 tiles away) and if they are disabled they should not cost much processing time.

    Probably two enemies at the same is a good rational limit for this engine, but I would have to test this more.

     

    Set the quality to 720p50Hz also for this..

     

     


    For the future: (whenever that is..)

     

    For Project X, it could be useful to force a max frame rate of 25 in PAL (30 or 20 in NTSC), so it is a little more stable.
    Now it can go from 50 to a little below 20 (in very specific points of the maze, looking in specific directions and with 2 objects active..
    but maybe I can optimize this worst case), so that variation may bother some people.
    In general I would say the average goes between 25 and 35 fps. So maybe locking the upper limit could be another option.

    Also, for any movement logic, is better to have a stable frame rate, but you can also solve this moving the logic to an interruption.

     

    The next step would be using better graphics for the objects, and that would require more complex clipping and lots of sprite frames :).
    This can be done using P/M's, or char based software sprites in Project X (there is space for that), or just software sprites, in Project M.
    I also need to move the optimizations and the object code to Project M, but maybe it would be more productive to start migrating everything to a cartridge.


    Regards!

     

    • Like 31
    • Thanks 2

  17. 5 hours ago, Mclaneinc said:

    Just out of interest, does PRINTSCREEN key give the same result?

    Nope (that would have been reeeally weird).

    I mean, PRINTSCREEN just save what you see in the screen at that moment in the emulator (the correct black).

     

    Something like:

    pp2.png.3b157152c505bf840077856ce5be9610.png

     

    Versus: (PAL artifacting, with "save frame")

    pp1.png.9af49dd159807b24d803b06e96f4398a.png

     

×
×
  • Create New...