Jump to content

Johan Kårlin

  • Content Count

  • Joined

  • Last visited

  • Days Won


Johan Kårlin last won the day on September 17

Johan Kårlin had the most liked content!

Community Reputation

30 Excellent

1 Follower

About Johan Kårlin

  • Birthday 08/09/1971

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I am sorry that I underestimated your knowledge. I am the grateful learner here. [emoji4]
  2. You're absolutely right! Finally I am getting it! And indexing makes it even better. Many thanks to both of you! This is exactly why I included the code, to see if someone could point out the weak points. I am not using this exact code anymore but use the same slow code in other places. Good to know it can be optimized. When updating the whole screen I have about half of the available CPU time left. No problem at this point but if the X16 ends up with a clock frequency of 4 MHZ I might run into trouble...
  3. Oh, sorry, I missed your comment. Thanks for taking time to read the code! But no, it will not work. I think you interpret BNE as testing if a number is even or not. It is only testing if it is zero. What I basically do is adding 1 to a 16 bit number (in this case an address pointer). This can be done most easily by increasing the lower byte all the way until it wraps from $ff to $00 at that point you increase the high byte and start over again with the lower byte. Do I understand you right? I am also trying to get a grasp on 6502 assembler, it’s been a while... and I haven’t really begun to learn until now.
  4. I think this is a great tool! Easy to use. But what happened to version 1.1?
  5. I love your texts, they are very well written and really bring the right atmosphere : ).
  6. I remember doing this on the Amiga a long time ago. I had great help by the book "Atari ST 3D Graphichs Programming" (https://archive.org/details/Atari_ST-3D_Graphics_Programming/mode/2up). Of course, the programming examples are in 68000 assembler but there are also lengthy explanations of concepts and methods. If you are familiar with linear algebra, it really helps. When it comes to hidden line removal, a method that is discussed in the book is to calculate the normal vector of each plane (polygon). If the vector points towards the viewer, the plane is visible, if it points away from the viewer, the plane is hidden. The limitation is that this only works on convex bodies. (On concave bodies planes can be partially visible.) If you ever wondered why all ships in Elite are convex bodies I bet it is because this method is used : ). Another method is to simply sort the planes and then draw the furthest plane first and the closest last. It works well on for example mathematically rendered 3D landscapes where it makes sense of talking of the planes as positioned in a specific order. If I take a guess, this is the method the game "Virus" used.
  7. I think that’s the answer I am looking for. I see a slight possibility to make it easier for the programmer. But from a hardware perspective it comes with a price that is not really worth to pay. You really seem to know everything about both software and hardware : ). While I am commenting on this - I think the easiest way to explain what I have been trying to say is this: When calculating sprite positions on a scrolling tilemap you are working with 16 bit arithmetics. The calculations are easy but you cannot rely on the fact that just because a position is bigger than the width/height of the screen the sprite will be off screen. You have to bear in mind that the values are wrapped at 1024 (=10 bits) and perhaps take actions in your code for this. I saw it as somewhat more convenient and consistent if 12 bits would be used, same as for tilemaps.
  8. Incredible work you have done! You must have worked really hard to accomplish this. I am very happy to see that you have added support for the X16. It is a great gift to the community.
  9. If I get you right, that is what I am doing. This thread is not about a problem I have. It is all about something I discovered when I had implemented this and everything worked just fine. I realized that the code for calculating sprite positions could be shorter, more consistent and easier to understand if sprite positions used 12 bits. But I might be confusing things. I suppose I have to give it some more thought. Thanks for taking time to answer.
  10. Thanks for your answer but this is not really what I am talking about. Sorry, it is hard to explain. Take a look at this drawing: We are just interested in x values for now. This is some kind of Defender clone with a tilemap that is 4096 pixels wide and it wraps around. The player is positioned at x position 100 and there are four enemy ships. How do we calculate the sprites' positions on screen? It seems really easy and consistent. Just take the distance between the enemy ship and the player and add 160. At first it seems to work, ship 4 even wraps nicely and turns up at x position 14. BUT there is one problem, ship 3 will (maybe surprisingly) appear at x position 236 (in other words be visible). This is because the tilemap wraps at 4096 and the positioning of sprites at 1024. 1260 - 1024 = 236. What I am saying is that if sprites was positioned with 12 bits instead of 10, this easy way above of calculating sprite positions would work. Now, at least less experienced game programmers like myself might find themselves in situations where sprites suddenly appear at random places : ).
  11. Well, I don't know if this really is a feature request. It is not at all important, but I think it's something worth to notice at least... Sprites are positioned with 10-bit value (0-1023). Tilemaps are scrolled with 12-bit values (0-4095). It seems logical because the highest screen resolution is 640x480 pixels and tilemaps are at most 4096 pixels wide or high. But let's say we're making a game that uses a tilemap that is 2048 pixels wide (128 tiles and a tile size of 16 pixels). Somewhere on the map is the player in a spaceship represented by a sprite. On different locations on the map are about 10 enemy spaceship sprites. When playing, the screen will act as a window into this "world" centered on the player's sprite. Scrolling the tilemap is easy, you just set the scroll values for the tilemap based on the player's position. Positioning the sprites are (almost!) as easy. The player's sprite will always be in the middle of the screen. All other sprite positions are easily calculated by subtracting the player's position. You position them by setting each sprite's x- and y-value. If they shouldn't be visible they won't, they will simply end up outside the visible area of the screen. Now you might think you are doing just fine. But this is not really the case. Because the tilemap wraps at 4096 and sprite positions at 1024. This means for example that an enemy spaceship that holds its position will turn up twice when flying from the left end to the right end of the tilemap. Therefore (if someone is still with me) it seems more logical and consistent to use 12 bits both for scrolling tilemaps and placing sprites. I absolutely understand that this is not at all hard to compensate for. I also know that in many cases it is wise to let the model have a coordinate system that is completely separated from tilemap and screen coordinates. But still, there are 6 unused bits left in the memory addresses that hold sprite positions, why not use two more of them?
  12. Every release feels like christmas. THANKS Michael Steil and everyone that have contributed! And a special thanks to @StephenHorn for the improvements to VERA! I have really been waiting for raster line and sprite collision interrupts! Great also that WAI is now implemented. I actually thought it worked already. I have been using it for quite a long time but the code must just have resulted in a busy wait... This must be the answer to why WAI (sorry, trying to be funny) has been so slow in response.
  13. I really got some good answers to that question, both from you and several others! When working on my own game I can still dream of more than 128 KB VRAM though. Now I manage to have a tilemap of 256x256 tiles by adding a software solution to what the hardware can offer. It is by far the most complicated and time consuming part of the game so more memory would have made a great difference. On the other hand it has been a fun and satisfying challenge! And sometimes I can’t make up my mind if I want more or less resources... As a whole I think the CX16 already has become my dream computer too.
  14. Great to hear! [emoji4] It is partly because of all people like you and me that share the interest and passion that I got inspired to start learning and programming.
  15. My first thought is to write a simple interrupt handler that is triggered on vertical blank. This avoids flickering. It checks a flag and updates a selected area of the map if the flag is set. Finally it sets the flag to false. I would update the map by copying memory directly to VRAM, no need to use kernal routines as I see it. Maybe you don't need to copy the color bytes? If that's the case you will reduce CPU time by 50%. In your Basic code, when the map should be updated - set the flag and also the row and the column of the topleft corner of the selected area by poking it somewhere in memory to pass the information to the ISR. (Of course, the flag isn't really necessary, you can also choose to set row and col to -1 when update shouldn't be done.)
  • Create New...

Important Information

Please review our Terms of Use