-
Content Count
753 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Member Map
Forums
Blogs
Gallery
Calendar
Store
Everything posted by R0ger
-
Collision detection - best practice
R0ger replied to Yaron Nir's topic in Atari 5200 / 8-bit Programming
Well I guess the main worry would be if the system is too free, it would allow player to get over obstacles he's supposed to get over. With game small as as Bruce Lee it shouldn't be too hard to simply test it. But I don't see how extra tests on logical level would harm the game. -
Collision detection - best practice
R0ger replied to Yaron Nir's topic in Atari 5200 / 8-bit Programming
Haha, that's great ! He's really sunk 1 pixel deep into the floor ! I never noticed. And anything which is same color as floor can be jumped onto. -
Collision detection - best practice
R0ger replied to Yaron Nir's topic in Atari 5200 / 8-bit Programming
I don't understand your question. Are you asking how Crown land is made ? I have no idea. I would test logical map what type of brick is bellow the player. And if there is chance of player being on the ledge, I would check graphics data of the current player frame combined with exact player coordinate. Probably using some small table. But let's analyze this game of mine https://atariage.com/forums/topic/283993-sails-of-doom-new-multijoy-game/ There are all kinds of collisions. Ship vs. shore is done by logical map only. I take coordinates of the ship, check what kind of tile is at those coordinates, and every tile has direction to which it pushes the player away from shore. Ship vs ship is done by another table. It's basically 2D array, 16x16, which tells me distance from coordinates 0,0. So I take relative coordinates of the ships, lookup the table, and I know let's say the ships are 10 pixels away. Let's say the collision limit is 8 pixels. So 10 pixels is 'no collision' case. If the distance is 6, ie less then 8, I know I have to move every ship 1 pixel in the opposite direction to solve the situation. Theb there is ship vs. shell. That also uses this distance 2D array, except the collision distance is smaller (IIRC), and there is also test for current shell altitude. There is also shell vs. terrain. I want shells which land on water to splash, but shells which land on ground to explode. And that is done by checking actual color of the pixel where the shell landed. If it's blue, I do the splash, otherwise I do the explosion. This game draws (mostly) everything in graphics, so to avoid ships, shadows, or other shells affecting this test, it is done in the moment all the moving objects from previous frame are erased, and the map is clean. -
Collision detection - best practice
R0ger replied to Yaron Nir's topic in Atari 5200 / 8-bit Programming
Typically you don't do collision with terrain with hardware collision. The PMG and the field have to overlap to generate collision. You want to stop the player BEFORE it overlaps though. Also there is one player (or two) so it's no big deal to solve the collision with terrain by other means. Typically you'd use your logical map data, most games have something like that. And you can always just check the correct pixels in the VRAM manually with CPU. Hardware collisions are more useful as detection of player getting killed. -
Run ahead ? I don't understand .. All I was asking is to pause the emulation when the surfaces are flipped .. or when VBI is triggered. I would need it step through animations frame by frame. And using debugger for that is not ideal, as it takes precious space on the screen.
-
Quick question .. is there a function to run simulation till next frame ? Of course it can be done somewhat easily in debugger, but outside of that ?
-
I usually test it by dumping random values into the desired scroll value. Also writing the value right after STA WSYNC is exactly the wrong time. You need few cycles after WSYNC, and it also depends on the values written. I never know the correct amount, I just test it. I find Altirra hadrware reference good in describing how it works and what all can go wrong, but it won't give you some 'best way to do it'. Is there something like that ?
-
Indeed. I'd say Dlists are quite cool. But PMG, GTIA color combinations, POKEY .. for every feature they have there are 3 limitations, and I keep wanting more every time I do something. But then, that's the fun part.
-
Resize the video to at least 720p, I suggest VirtualDub. It's nice video tool made by some Phareon, you might have heard of him. Youtube handles videos with 720p and more as HD, will use better bitrates, and also will store them at 50/60 fps. Comparison of how it looks (shameless plug): naive approach first: https://www.youtube.com/watch?v=SXYFQONJHBQ and 720p version: https://www.youtube.com/watch?v=BjNm04oCdYc Also check the available frame rates.
-
That's how an A8 racing game should look like... ;)
R0ger replied to Heaven/TQA's topic in Atari 8-Bit Computers
I tried just that. That was actually my original idea about PMG road. And the answer is .. no. There is limit how much to the left you can do it. You can't stretch the road to the left border of the screen. This is analytic view (ctrl+F8) in Altirra. You see that vertical yellow line ? That's basically the limit. Maybe the left side could be covered with another PMG object .. good luck with that though, this trick needs to be done on specific cycle, and the kernel for drawing road via PMG is complex even without it. -
That's how an A8 racing game should look like... ;)
R0ger replied to Heaven/TQA's topic in Atari 8-Bit Computers
That wouldn't be too hard. XOR wouldn't work though, as you have to combine it with the cars in front, and if you do 3rd person view, with player's car. But the whole road in PMG is really nasty dense kernel code. You don't even have enough time to move all the PMG objects per line, I do left side on even frames and right side on odd frame. Adding hills would mean the kernel code has to be active for even taller portion of the screen. That eats into available CPU power. Also PMG have one great feature - they can all have different color. This cannot be used here. If I ever go back to this topic, I would like to experiment with full software rendering and character modes. -
That's how an A8 racing game should look like... ;)
R0ger replied to Heaven/TQA's topic in Atari 8-Bit Computers
Well if you want some center line on the road, and you want to use PMG for that too, you have only 3 PMG left for the road. And that won't fill the full screen width. -
All demos can be downloaded for example on pouet: https://www.pouet.net/party.php?which=438&when=2019
-
That's how an A8 racing game should look like... ;)
R0ger replied to Heaven/TQA's topic in Atari 8-Bit Computers
You simply can't make cars and 50fps. You can use hardware to have nice road .. and the use PMG for cars. Problem is, Atari's PMG is too limited, and you end up with simple cars. I tried using the opposite approach .. PMG for the road, field for car, which simplifies things greatly, see here: https://www.youtube.com/watch?v=2iT2_PdJa3g But there is too many limitations, mainly width of the road, I don't think it's the right way. Or you can do it like Electra Glide - first person view. That would be possible even with more complex road and hills, but having tried myself, I must say even that would be an achievement. Other than that, you have to use software sprites. But then that's the same for most 8 bit platforms. You could go for fake road .. like C64 outrun https://www.youtube.com/watch?v=Jt7xn_K6WX8 The road is just few frames, made from charset, and it only scrolls to the left and right, no distortion is made. Really fast to render. You still have to do the cars somehow though. Game like this is more about evading other cars, rather then following the road perfectly. It's not what I would expect from a racing game, but it's also fun. Also games like Chase HQ on spectrum us characters to some extent https://www.youtube.com/watch?v=s2aYrkofKHM You can see how the road itself is actually done using characters, and the bends are only on multiples of 8. Also the cars are not merged with background, and are only on character boundaries. Only the player car is merged with background. It's all software rendered, they just used every possible trick to make it simpler, thus faster. -
That's how an A8 racing game should look like... ;)
R0ger replied to Heaven/TQA's topic in Atari 8-Bit Computers
I'm first to say you don't need 50fps, but this seem too slow .. I think 2 frame refresh would be ideal, 3 or 4 acceptable. -
Haha, glad it's ok. Boxed packages are incredibly expensive, like 18eur for the smallest, so the envelope was the only reasonable solution. You will have to clean the edges of the buttons and such, I just removed the brim. And don't file too deep, none of this is completely solid inside. PS. Sorry for forgetting about the chocolate
-
On the topic of managers .. just in case somebody missed this one .. sorry https://www.youtube.com/watch?v=BKorP55Aqvg
-
Unicorns season: Prince of Persia for the A8!
R0ger replied to rensoup's topic in Atari 8-Bit Computers
As XXL noted above, but not really explained, there is BRK instruction there, and Altirra is often set up to stop on BRK. So check the CPU options, and uncheck 'stop on BRK', and try again. -
Maybe with fixed drill, but in hand this drill is totally unusable. It's also somewhat rough, it's usually intended for dry wall.
-
I use cone drills. They don't center perfectly either though. Mounted drill and fixed object is the best way. If you do it in your hands, just drill a bit, check how off it is, and try to correct it by pushing to the side. I usually leave last few tenths of mm to finish it with file. One day I will make 2D laser cutter, and that should solve the problem once for all
-
The games will work. You just need to move Sega's +5V to Atari's +5V, the rest should stay as is. But the worry should be about Atari, not the controller. If you are OK with powering the controller from data lines, go ahead. The power is most likely pretty small. As for the controller which did that it was some Chinese copy, 3 button, IIRC.
-
Using Sega controllers directly isn't really recommended. They take +5V from different pin, and on normal circumstances, they draw the current mostly form the data lines. While I don't know about case where the Atari would get damaged, it's not really intended to be used like this. Worst I've see was that the controller stopped working after time, and working again after reconnecting. At least use simple wire-swap to move +5V to where it should be.
-
K5000S has very nice sounds. But it's combination of additive / subtractive. And it seems to have way more voices. I found video where guy praised additive synthesis greatly, but from today's standpoint, where you have unlimited memory a cpu power. You can take any sound, analyze it to 100 harmonics, and then recreate the sounds, while being able to modulate the process. Like for example having the harmonics differ for low and high notes. He even mentions AI approach. You take hours of recording of some instrument, like cello, which is very hard to reproduce well. You FFT, throw it into AI. AI can then recreate the sound from just notes, even adding expression and dynamic. For something like that, additive synthesis is obviously the best. Could be also used for MP3 decompression Not sure how the lack of phase control matter though.
