Jump to content

NRV

Members
  • Content Count

    422
  • Joined

  • Last visited

  • Days Won

    2

NRV last won the day on September 1 2017

NRV had the most liked content!

Community Reputation

520 Excellent

About NRV

  • Rank
    Moonsweeper

Recent Profile Visitors

16,480 profile views
  1. 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
  2. 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.
  3. NRV

    Chess

    Nice page. I add a vote for the ideas in Really Bad Chess. It "seems" easy enough to implement and is a lot of fun to play x)
  4. 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).
  5. 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: 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: 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).
  6. Thanks for the feedback, everyone. 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) 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. 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. 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. 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 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.
  7. 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. 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!
  8. What happens if you restore the emulation to normal settings (normal speed, collisions on) just before the crash?
  9. 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: Versus: (PAL artifacting, with "save frame")
  10. Well mads has the precedence in the documentation: Operators Binary operators: + Addition - Subtraction * Multiplication / Division % Remainder & Bitwise and | Bitwise or ^ Bitwise xor << Arithmetic shift left >> Arithmetic shift right = Equal == Equal (same as =) <> Not equal != Not equal (same as <>) < Less than > Greater than <= Less or equal >= Greater or equal && Logical and || Logical or Unary operators: + Plus (does nothing) - Minus (changes sign) ~ Bitwise not (complements all bits) ! Logical not (changes true to false and vice versa) < Low (extracts low byte) > High (extracts high byte) ^ High 24bit (extracts high byte) = Extracts memory bank : Extracts global variable value Operator precedence: first [] (brackets) + - ~ < > (unary) * / % & << >> (binary) + - | ^ (binary) = == <> != < > <= >= (binary) ! (unary) && (binary) last || (binary) I tried to see it your way, but I couldn't.. I feel that mads is doing the right thing, but maybe is out of habit But I think I would find it strange if: "<LABEL + 1" is different than "1 + <LABEL" ..
  11. Don't know why, but in the last tests, if I do "save frame" with "PAL artifacting" (and only with that artifacting mode), the black backgrounds is a light gray instead..
  12. Nice... never used it, but always believed the common myth about it, that the overflow bit indicates a carry (or overflow) from bit 6.. x)
  13. That's the correct "generic" way of doing it, but you also could have different logic for different "quadrants" for the ray (centered in the viewpoint position). So, for example, a ray moving in a "top-left" direction, could check X against the 0 limit and Y against the 256 limit only (assuming coordinate Y grows from "bottom" to "top"). Also, you normally trace rays from left to right ("clockwise"), so you don't change "quadrants" that often.
  14. I have not seen your code, but the basic algorithm should be something like: loop: - sync to some screen line - show screen buffer 1 work on screen buffer 2: - erase previous sprites in buffer 2 (needs a list of the positions and sprite types previously drawn in buffer 2) - update real sprite positions (and animations, creation, destruction..) - draw sprites in buffer 2 (save positions/types in list for buffer 2) - sync to some screen line - show screen buffer 2 work on screen buffer 1: - erase previous sprites in buffer 1 (needs a list of the positions and sprite types previously drawn in buffer 1) - update real sprite positions (and animations, creation, destruction..) - draw sprites in buffer 1 (save positions/types in list for buffer 1) jump loop:
×
×
  • Create New...