6 Digit Score Display Not Working

[Endless Runner 2600]

Project Canceled

Edited April 29, 2019 by Endless Runner 2600

[azure]

There are a few problems.

• The code is not writing to RAM, because there's no RAM segment, so the memory writes are being ignored.
• The 6 digit drawing code is inside the vertical blank, so it will never render on screen.
• NUSIZ needs to be set to 3 copies close.
• sta HMOVE should immediately follow sta WYSNC due to timing reasons.
• DrawDigits is incorrect, because you're using absolute indexing. It needs to be indirect indexed otherwise it messes up the timing. Example: lda (VAR),y
• DrawDigits is position sensitive, so you need to horizontally position sprite 0 to position 56 and sprite 1 to position 64. Timing must be exact.

 

I uploaded a modified copy that shows the score working. I had to comment out the player movement section, because the PosObject interfered with the 6 digit score. Some refactoring is going to be needed to keep the multiplexed sprites within their own horizontal sections.

 

If you had intended for the score to be non-centered on the screen, you'll have to fiddle with the routine and positioning to make the timing work.

Edited April 29, 2019 by azure

[Endless Runner 2600]

Project Cancelled

Edited April 29, 2019 by Endless Runner 2600

[JeremiahK]

The way I would do it would be setting the playfield to reflect mode and using PF1 to draw the main character, since it doesn't move left or right, only up and down. Then I could use both player objects to draw the enemies at quad size, allowing 2 enemies on screen at a time, per row. This would allow adding elements like multiple enemies with different colors, pickup items, etc.

This would require changing the playfield color twice on every scanline, so the playfield could be drawn in the player's color on the left side, but the right side would be the same as the background color to make it invisible.

Both missile objects would also be free, in case you wanted to add a shooting element to the game. Lots of possibilities!

 

You could also scale down the size of the players to allow more on-screen at a time using NUSIZ to copy the players, but the playfield could not also be scaled down.

 

I am actually working on a similar concept, but at a different scale. You can check out my project thread, if you are interested. I haven't posted in awhile, but have been doing some work in it lately.

 

Also, when you post a large piece of code (50+ lines or so), it's a good idea to include it as a file.

Edited April 29, 2019 by JeremiahK

[Endless Runner 2600]

The way I would do it would be setting the playfield to reflect mode and using PF1 to draw the main character, since it doesn't move left or right, only up and down. Then I could use both player objects to draw the enemies at quad size, allowing 2 enemies on screen at a time, per row. This would allow adding elements like multiple enemies with different colors, pickup items, etc.

This would require changing the playfield color twice on every scanline, so the playfield could be drawn in the player's color on the left side, but the right side would be the same as the background color to make it invisible.

Both missile objects would also be free, in case you wanted to add a shooting element to the game. Lots of possibilities!

 

You could also scale down the size of the players to allow more on-screen at a time using NUSIZ to copy the players, but the playfield could not also be scaled down.

 

I am actually working on a similar concept, but at a different scale. You can check out my project thread, if you are interested. I haven't posted in awhile, but have been doing some work in it lately.

 

Also, when you post a large piece of code (50+ lines or so), it's a good idea to include it as a file.

This sounds very complicated is there a tutorial?

 

Edit: Actually since your working on something similar anyways, nevermind I canceled the project.

Edited April 29, 2019 by Endless Runner 2600

[azure]

I was replying right as you updated. What I meant by refactoring is the 3rd PosObject call just needed to happen after the digits were drawn.

 

Also, there are a lot of 2600 games that are similar, because the nature of the hardware forces the same limits one every game. I wouldn't worry about it. I think a bunch of projects end up being something different from what they started out as, because you find out some designs either won't work or you think of better game elements that change the dynamic of the game.

Edited April 29, 2019 by azure

[Endless Runner 2600]

I was replying right as you updated. What I meant by refactoring is the 3rd PosObject call just needed to happen after the digits were drawn.

 

Also, there are a lot of 2600 games that are similar, because the nature of the hardware forces the same limits one every game. I wouldn't worry about it. I think a bunch of projects end up being something different from what they started out as, because you find out some designs either won't work or you think of better game elements that change the dynamic of the game.

I'm sorry, but I deleted all the source code already. As I said the project has already been canceled. Edited April 30, 2019 by Endless Runner 2600

[azure]

I deleted your files I uploaded in my comment in order to respect your wish to delete your program. If you ever want them back, send me a PM.

 

I'm just very puzzled by this thread. Development for the 2600 is hard. It requires an extraordinary level of patience and rework. In many ways it's very different from traditional game development, but in other ways it's identical. My game isn't complete, but it's getting close. The lessons I've learned from this unusual series of problems have made it a very satisfying intellectual challenge. I'm only just scratching the surface. I'm still working out how 2600 shoot'em ups manage to multiplex so many sprites. It's one giant puzzle of lots of smaller puzzles, which appeals to me a lot. It requires a level of stubbornness and resilience to frustration. I suggest you keep trying. There's no requirement that your final game design be the same as the initial design. You could end up with a completely different game, and nobody is going to judge you for it. If it's turning out not to be your cup of tea, that's fine too. There's plenty of other platforms you can code for.

[Endless Runner 2600]

I deleted your files I uploaded in my comment in order to respect your wish to delete your program. If you ever want them back, send me a PM.

 

I'm just very puzzled by this thread. Development for the 2600 is hard. It requires an extraordinary level of patience and rework. In many ways it's very different from traditional game development, but in other ways it's identical. My game isn't complete, but it's getting close. The lessons I've learned from this unusual series of problems have made it a very satisfying intellectual challenge. I'm only just scratching the surface. I'm still working out how 2600 shoot'em ups manage to multiplex so many sprites. It's one giant puzzle of lots of smaller puzzles, which appeals to me a lot. It requires a level of stubbornness and resilience to frustration. I suggest you keep trying. There's no requirement that your final game design be the same as the initial design. You could end up with a completely different game, and nobody is going to judge you for it. If it's turning out not to be your cup of tea, that's fine too. There's plenty of other platforms you can code for.

That's not the issue. The issue is if someone else is already making the same game, there's no point in having 2 games that play exactly the same. I can try to recover my source code and see what happens, but no guarantees. Thanks for removing the source files. Edited April 30, 2019 by Endless Runner 2600

[Endless Runner 2600]

How would I draw the player using PF1?

[azure]

The process is almost the same as drawing sprites using GRP0 or GRP1. The kernel steps through each line, determines if the sprite should display, fetches a row of sprite data, and writes the data to PF1. Using the playfield for a sprite means accepting a few sacrifices. No horizontal positioning. It can only move up and down (unless you come up with a scheme for moving it across PF0/PF1/PF2.) It's also going to have chunky resolution: 4 color pixel wide block.

 

There are two tutorials I know of:

 

Andrew Davie's tutorials

 

http://atariage.com/forums/topic/33233-sorted-table-of-contents/

 

Nick Bensema and Random Terrain's tutorial on the playfield:

 

http://www.randomterrain.com/atari-2600-memories-how-to-draw-a-playfield.html

Edited April 30, 2019 by azure

[JeremiahK]

I would like to clarify something. When I said I was working on a similar project, all I meant was a side-scroller with a player object that only moves up and down, and sprites that move right-to-left. In my game, there are "good items" you want to collect, and "bad items" you want to avoid. It is NOT, however, the same as your idea. I haven't even actually started on the gameplay aspect yet, it's basically just a demo for the kernel at this point. I am still figuring out what I want to do. Plus it's a Nyan-Cat themed game, so it is very different from your idea, actually.

 

I hope I didn't scare you off with an overload of information. I wasn't sure how much you knew about the hardware, and it seems that you are still a beginner. That's perfectly fine, all of us had to start at that point. Follow the links azure posted above, and that will give you the basics. Start with something small! My first project was a super-simple bouncing-dvd-logo style mini-demo. As stated, if this just isn't your cup of tea, that's fine, but if you push yourself through the learning process, you will be able to do things you never imagined possible.

[+Random Terrain]

Random Terrain's tutorial on the playfield

 

http://www.randomterrain.com/atari-2600-memories-how-to-draw-a-playfield.html

 

Just to be clear for people reading this in the future, that's not my page. It's just on my web site. It's by Nick Bensema and adapted by me so it will have a certain look and clickable table of contents.

 

I also have other assembly language pages on my web site, including the tutorial by Andrew Davie:

 

randomterrain.com/atari-2600-memories.html#assembly_language

[azure]

 

Just to be clear for people reading this in the future, that's not my page. It's just on my web site. It's by Nick Bensema and adapted by me so it will have a certain look and clickable table of contents.

 

Ahh. Thanks for letting me know.

[Endless Runner 2600]

I would like to clarify something. When I said I was working on a similar project, all I meant was a side-scroller with a player object that only moves up and down, and sprites that move right-to-left. In my game, there are "good items" you want to collect, and "bad items" you want to avoid. It is NOT, however, the same as your idea. I haven't even actually started on the gameplay aspect yet, it's basically just a demo for the kernel at this point. I am still figuring out what I want to do. Plus it's a Nyan-Cat themed game, so it is very different from your idea, actually.

 

I hope I didn't scare you off with an overload of information. I wasn't sure how much you knew about the hardware, and it seems that you are still a beginner. That's perfectly fine, all of us had to start at that point. Follow the links azure posted above, and that will give you the basics. Start with something small! My first project was a super-simple bouncing-dvd-logo style mini-demo. As stated, if this just isn't your cup of tea, that's fine, but if you push yourself through the learning process, you will be able to do things you never imagined possible.

You didn't scare me at all. I just don't want to "compete" with another project. The reason being, because it may cause the people watching the other project to lose interest in it and deflect to the "new shiny toy". It just wouldn't be right if no one was interested in your awesome game because of me.

[JeremiahK]

This will be my last post on here. If that is your final decision, I will respect it. But once again, I say that your idea is quite different than mine. The only reason why I referenced mine was because I thought it might help you to see how I coded my kernel, because it might give you ideas on how you would implement yours.

This community doesn't play favorites. There aren't a lot of people writing code for 2600 games, so all projects are appreciated and encouraged.

Regardless of what you decide to do, I wish you the best in your next endeavor! This forum is always open to you, and willing to help any issues you run into!

Edited April 30, 2019 by JeremiahK

[+Karl G]

Adding to what has already been said, people work on similar-style games all the time. If that's what is holding you back, then I suggest not worrying about it, and making what sounds fun to you. That may be the project that you finish, or it may be a project you don't complete, but learn from along the way (I have many of the latter variety myself).