Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

743 Excellent

1 Follower

About vitoco

  • Rank

Contact / Social Media

Profile Information

  • Gender

Recent Profile Visitors

7,015 profile views
  1. Changelog: A "back bounce" variation was added to both current games. A third game (zig-zag) was added, including the "back bounce" variation. The 2K limit was exceeded. I had to move the starting address to $8000 for a 4K ROM and found that my code finishes at $F814, that is just 26 bytes more than the 2K limit (20 bytes plus 3 vectors), so I have to go into the code optimization. The code has 6 selectable games in total, but I really want to include the controlled bounce game and a "crazy" game (to randomly change the game type on every bounce or round), and I think that those don't require too much extra bytes to keep a 2K version. I don't think that my code was quick and dirty, but I know I have to finish the mini sound tracker and save many bytes from the FX data by compressing them. I feel that all my previous packaging and optimizing experience with BASIC tenliners would help here, at least to decide which features to include in the final version and which ones to remove. Let's see how this goes... BTW, about NTSC vs PAL: Which is the current procedure or best practice to make a game to look and feel the same on both systems? Adjust color palettes, the number of scan lines, drop or repeat frames for speed, compile both versions or allow a single version to autoadjust, ... Links or hints? 🤔
  2. I was thinking about a fractional method to implement what I called "parabolic bounce", but I had my concerns about it on where to position the player (rounding vs truncating) and how it would work on edges. When I got stuck and frustrated, I took a breath, calmed down and started to implement the two bytes routines for testing purposes and applied it to the standard gameplay, which it could allow me set speeds from 0.5X to 1.5X. I was looking for "rounding" techniques on binary numbers (like checking for bit 7 of LSB) when I found the "subpixel" concept. Thanks Darrel. Most of the improvements in my code are due to your posts and tutorials. 😬 BTW, I kept truncation because, after all, I was already truncating on edges for 2X and 3X speeds, so it seemed to work fine also with fractional speed. Also, "parabolic bounce" didn't look good enough during the gameplay and became "curved bounce".
  3. I went into another solution: 16-bits coordinates for each axis, one byte to match the pixels and another for a fraction of a pixel. Doing this way, I can advance just 3/4 of a pixel on each frame adding $C0 to the LSB byte (with carry into the MSB). Unfortunately, the horizontal pads also doubles the speed of the vertical ones, so slowing down the ball increases the difficulty when the ball moves diagonally. I've thought about that, but it is not a priority. That would need change in the kernel for the pads at the top and the bottom of the arena. By now, I'm trying to keep this game within 2K. Thanks for your comments! Updates: Changed the coordinates system into a 2 bytes one. The MSB stores the actual pixel position on screeen and the LSB is used as "decimals" or a fraction of pixels (subpixels). This allowes the ball to bounce on any desired angle, and to slow it down if needed, but sometimes the movement seem to be a little jerky. Some random bits are included in the LSB to enhance difficulty. Completed a game with increasing difficulty (in speed and bounce angles). Some fine tuning might be needed. Completed a game with curved bounces and increasing difficulty, but fine tuning might also be needed. Enabled the Game Select switch to select the game. Next steps: Include a game where the direction could be controlled by the pad during the bounce. Include a game with a zig-zag (tron like) movement of the ball. Include backbounces as a variation for the completed games and the now ones. Make some changes in the code to reuse routines from the completed games in the new ones. Stay tuned!!!
  4. Numbers are required by the cart, but they are not relevant for the code as there is no GOTO or such, just labels references for branches and jumps, so the numbers can be sequentially created by the bot after it receives the code and before submiting it to the cartridge.
  5. That's awesome! Do ASM really need line numbers in the message? Without numbers (and one of the following spaces) you can save message space for larger code, and the numbers might be sequentially included for free (like the "*=$3000" line). I guess that if the message does not include a trailing RUNAD, the bot will automagically include $3000 as the entry vector. Some other optimizations could be made to avoid errors in the message, like making the leading space optional, and inserting them with the numbers, except for the labels. How to know there is a label? It might not be a reserved word. You can even use a delimiter and send all the instructions in a single line! I haven't tested this bot, because I don't have a Twitter account...
  6. I'm testing it with my new tenliner... Thanks! ++V
  7. I added randomization to the play in the following ways: The ball starts rolling to any of the 4 corners. The ball might be randomly bounce at normal speed or double speed (very like the original A8 version of the game). But I'm quite frustrated! The game becames unplayable... I had to limit that only horizontal or vertical speed might be doubled, but not both at the same time. It's still too fast!!! The most I could get was 28 points. I've attached the updated demo to let you try it and to answer the following question: How could I solve this ball speed issue? Freezing some frames? Slowing down normal speed to the half of it, so what I called "normal" becames "fast"? Allowing fast speed only on the vertical axis? Thanks! ++Vitoco dontgo-20200919-demo.bin
  8. Ball will start to a random direction, but always from the center. For now, it starts always to the upper left just because I was testing the addition of negative numbers I haven't tried random numbers yet, and I guess I should start with any algorithm really soon. Currently, there is a sound that it can be heard every 10 points... the idea is to signal that something different is happening (speed up, zig-zag, gravity, parabolic, ...) Of course, current sound FXs are experimental. They should be better! There is about two pages free, that's a quarter of the 2K limit. I'll try to fit in that space, but I think that some features would require more data tables, and that probably make me go for the full 4K ROM. I hope not. Thanks for testing! ++V
  9. I'd appreciate it very much, but I don't know exactly what's wrong with my console. There was a flood in my neighborhood in 1984, and I managed to recover the console among many things from the mud, but I never took the time to do a restoration, which I only did to the controllers so I could use them in my brand new 800XL ('til today). A few years ago, I took my 2600 to a local retro meetup event and turned it on for the first time in about 30 years. It worked fine for a few minutes and then some garbage appeared in the TV screen. I have to do a real cleaning of it and see which components need to be replaced, and I'll do that as soon as I finish this project. Whoops... a naked PlusCart!!! 🙈 When I'm trying to adjust the scanlines but I fail to tune the timers, Stella automatically changes from NTSC to PAL and displays those colors (the score should be purple instead of red). Now I see another "problem": the height of the vertical pads becames larger in PAL than in NTSC. I tried to adjust them to fit the width of the horizontal ones. I'm not sure if I need to either dynamically adjust their size (and the whole arena height) to make them look similar. Even the ball doesn't look square and a scanline should be removed from it. I have to think about this... Thanks for the picture!!! Yes, it is predictable, and that's why I called it a "practice level". As I'm using a single line kernel, I have no room to add visible obstacles using the playfield, and if I could, it would be of the same color of the ball, unless flickering is used, and I don't want to do that in my first project. That's why "invisible walls" are in my list... but I'll try different types of bounces first.
  10. "Don't go" is a single player game. The full story is in its description page as a BASIC tenliner (about 70 statements in 10 lines of BASIC code). To play it in Stella without paddles+Stelladaptor, you can use the mouse, moving it horizontally. All 4 pads will move at the same time: opposite pads move on different direction, but both clockwise or counterclockwise. Vertical and horizontal pads move to the same corner at the same time, so a hit in the corner might be saved by the same move. Is this a common practice today for the VCS? I didn't see that in the 80's. I think that doing this port change would counfuse Stella players, because the mouse won't work. This is what I've thought: - parabolic bounce - zig-zag bounce I found this a very interesting idea to test, because even when some of the rules are hardcoded, most of them could be changed at compile time. Before taking some action, (while in the shower) at first it seemed to me that the difficulty would be greater in a smaller area because the player would need faster reflexes, but it turns that a smaller area has less space to let the ball escape, because the pads would always have the same size. In the extreme, the ball would be surounded by pads and no free space to escape. I changed the way I code all the same time while I'm learning about this machine, and instead of counting the scanlines as I initially did, I moved to the use of timers. Unfortunatelly, formulas using integer arithmetics need some tunning and also timeouts don't fit scanlines, so I left them just as they worked for me in the Stella emulator. But at @atari2600land's notice, I went into Stella's debugger, and I found that the scanline counter starts from zero when exiting the VSYNC lines, so I had to count all the scanlines that timers provide. In total, the kernel was using 194 scanlines instead of 192, and the overscan had a lot less than the required to get 262 in total for NTSC. I adjusted the timers and sent him a new binary to test. I'm glad that it is working anyway on real hardware and CRTs, but I want to write a game that it could be playable everywhere, both NTSC and PAL, real and emulated. If I could make a cartridge with it, I'd be happy. Of course, if it becames an interesting game, it could be great if it is published, but that's another story where I don't know a single word on how that works. Could you be more specific on what do you need? BTW, it looks like this PlusCart is something to seriously consider. But first, I need to repair my old VCS. ++V
  11. Excelent page! That is a very good start point to select some values and to mix them for an FX. My mini games are just that: mini-games. They might be awesome because you know there was a tenliner restriction when I wrote each of them. But I have fun programming them, trying to get the best of the available resources and, the most important, playables!!! I already have 2 (unpublished) games ready for NOMAM 2021 contest and 2 more developements stand-by. Games for the 2600 became my source for ideas in the latest years, but I wanted to give me a break on BASIC tenliners and tried going in the other direction: from A8 tenliners to 2600 games. It seems that I like to suffer with extreme programming, and I had knocked my head against the keyboard trying to get the things on sync just like when I had to fit statements in lines for a tenliner. Updates on "Don't go!": It supports many lives now. The A8 game is a single life one. Right difficulty switch selects between 1 or 3 lives (0 or 2 extra lives). Paddle's trigger restarts the game on certain conditions I've attached a new playable demo. It has just one type of bounces, totally predictable, but hard enougth, like a practice level. Both difficulty switches are working, and TV type switch changes between color and B/W. Using any of those switches abort current game. Use game reset to (re)start the game. There are some FX sounds included for testing purposes. Please try it and comment... If someone tries it on a real console, please let me know how it feels with real paddles. If a CRT is used, please post a photo. As usual, any idea is welcome! dontgo-20200917-demo.bin
  12. Thanks! The new changes are: It has sounds with a simple FX tracker I'm writing. I have to experiment a lot more with the available AUDCn modes and the 5 bit only AUDFn to get good quality sound effects, not just peep and toot. The game is playable, because the ball bounces only on pads, not on every border... Now I'm scared!!! Even when I'm using simple diagonal bounces, it is a bit faster that the original game, and it seems to be very difficult. A difficult game immediately turns into a frustrating game when there is no extra motivation to try again other than a hi-score challenge. I need to add many more elements to keep it as an intereting game to try, and try, and try again. When I first saw your 9lineBlitz some years ago, I tried to update myself about current VCS' state-of-the-art. I think that it was the first time I considered to write something for the 2600, but as I said in my first post of this thread, I needed to learn more about the hardware and then I forgot that for some time. Then I tried again with bB, but quit it some days later. What it made me to discard trying a tenliner for the 2600 was all those very long names to control features like "SUSTAINFORFRAMES" or "playfieldpos". Also, the lack of structured programming that it cannot be distributed in the middle of different lines of code makes hard to get the most of every line. Just like 8bit's AtariBASIC, having only 10 destination lines for GOTOs is a real challenge, but with the lack of line space, that makes almost impossible to write a playable and enjoyable game. Of course, I'm aware of some BASIC's builtin features that could be used to make a great game, but that requires some previous experience, and I'm on it!!! Also, I've found that the resulting binaries require upgraded hardware like Supercharger, Harmony and Melody cart provides, and that's another new world for me. Be patient... In this first stage I'm trying to create my first VCS game using the original programing techniques, and I'll try to burn my own 2K ROM/EPROM with it 😬
  13. Hello... Which is the recomended max value for the volume of a tone to be stored in AUDV0 and AUDV1, if any? Is 15 the usual max value for each channel? And for both channels combined? For 8bit computers, it is suggested to not abuse of it, so the combined volume for all 4 voices of the POKEY chip at the same time should not be more than 32 (4*8 or 2*12+2*4 or any other combination), even when it is possible to use all the power: 60 (4*15). I've not found any reference about such a suggestion for the 2600's TIA chip. Thanks in advance!
  14. I'm doing almost the same thing in my own routine, but twice, because I put both (C+V) and (x+F) bytes in a single stream of data (as words instead of bytes), increasing Y register twice in a loop to read both. "x" would be a duration indicator using the upper 3 bits of the frecuency byte (not implemented yet). Ouch! Well, it also looks ugly to me. I'll turn into two blocks and see how much better it looks.
  15. Updates: Reorganized the code again. I started programming in a sequential way to fit the VB, kernel and OS display, but I think that its better to make blocks of code like in routines for legibility, even when I lose 12 cycles for each JSR/RTS pair. Managed the console buttons: - TV type selects color and B/W mode - left difficulty switch changes the pad size - right difficulty does nothing (yet) - game select does nothing (yet) - game reset restarts the game (all but reset returns to the game selection screen) Added a bounces counter (score). Now it looks like this: - Normal - Pro in B/W Now, I'm starting with the sounds. My current kernel is a single line one, so I have no machine cycles free to add a check for the second POT (paddle). Anyway, I'll left the gamplay as the last item, because I'm still thinking about different difficulties for the game. Some ideas are: - increase the ball speed every X bounces - control bounce direction (depending on which side of the pad the ball hits) - bounce with random angles/speeds - lives & bonus (currently there is only one life) - introduce gravity to change the ball direction - introduce invisible walls to block and return the ball - all the previous in stages/levels and combinations of them! More ideas? Everything is welcome!!! Stay tuned!
  • Create New...