Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by jbs30000

  1. The option to save in binary, hex, or dec is no problem. I'll add that right away. Vertically scaled "pixels" is a great idea. I'll probably have to implement them a little bit later, but I will do that.
  2. Thanks, but that's the old program. Have you tried the new one from post #14?
  3. OK, here's an update. The changes are as follows. 1. You can now change the background colors. 2. You can draw and color sprites. 3. You can load playfields, foreground, and background colors. You cannot save them yet. Turns out the color grids I have should be tall instead of wide. When loading colors I have to swap the bytes around (I.E. $A4 is read as $4A). The program is made to ignore most errors regarding numbers. For example, invalid numbers (l0 instead of 10) and missing numbers will be replaced with zeros. The program will tell you this, although it won't tell you where the errors are. Included is a sample project file, playfield file, and foreground and background colors files. Place everything in the same directory. In case you can't tell, the playfield is a sun, tree, and some grass (I just did a quick, basic image. Screw quality 😝.) Edit: I haven't tested loading symmetrical playfields yet. If you want to load one it will load it as a repeat, unless, on the very first line you include the word reflect. Simplified_Editor.exe Test.prj Scenic.asm BGColors.asm PFColors.asm
  4. BladJunker. First, the left mouse button is for drawing the foreground, and the right button for the background. Second, please explain in more detail what you are looking for. Everybody else. I fixed two problems that I only just noticed. First, When you pick a new foreground color the playfield should refresh but it didn't. Also, a tiny spelling error kept the background color from being able to be changed. I completed the sprite editors and I'm almost done with load functions. After testing them out I'll post the updated sample program.
  5. I'm not sure what that means. Sounds like you're looking for a programming IDE and image editor combo.
  6. Well, I have the sprite editors complete, except for problems with undo and redo, which I don't have for the undo and redo for the playfield editor. Edit: Turns out there's a problem with undo and redo regardless of which editor, so I'm re-writing that before moving on to load and save functions.
  7. So long story short, I stepped away from this for a while, and when I came back, I saw how messy everything was, from the form itself to the coding. So I've started over and have a much better editor. It's not complete, but very close. It can't open or save files yet, and the sprite editors don't do anything. Enabling the sprite editors will be easy. For the loading and saving, I'll probably have to code from scratch because when I look at the code from the old program I can hardly make heads or tails of it. Also, I have a button that I don't know what function to assign it, if any. Suggestions would be appreciated, thank you. Edit: I'm also going to try and improve the rotate function. Edit 2: Sorry, the text also doesn't work on this demo. Edit 3: Boy do I feel stupid. Select, select all, cut, copy, and paste also don't work 😪. But that's all, I swear. 🤞 Edit: Post 14 has the newest version. Simplified_Editor.exe
  8. Edit, finally have an update. See post 6. So I've created a playfield editor based on common image editors. There's some unfinished features and I regret how I implemented the text tool. I will complete and improve the program, but I need to re-code a bunch of it first, because what started out as neat and orderly coding got sloppy pretty quick. Anyway, you can draw pixels on it, draw shapes, type text, import an image, flip or rotate, etc... It saves the playfield the same way that the FSB tool in the Andrew Davie tutorial does, but before each strip it ads a SEG and then an ORG <segment>. You can also load a saved playfield back into an image and edit it some more if you want. I'll call this my beta version; What the heck. So if you're interested, give it a try. Feedback is always appreciated. I hope you like it. 2600_Playfield_Editor.exe Quick manual.pdf
  9. OK, instead of BEQ overscan I changed it to BNE DrawLoop. Getting rid of the JMP gained 3 extra cycles for a total of 4 free cycles total. And getting rid of the STA WSYNC will get rid of 3 more for a grand total of 7. I could make the sprite multi-colored, but it's for the best if I make my personalized SkipDraw, actually it's a DoDraw, into a standard DoDraw. Anyway, it's 3:07am so done for a while.
  10. I'll be honest. I haven't touched bB in about 9 years. The QBert.bas code is here, http://atariage.com/forums/topic/124726-qbert-game-completed-formerly-titled-ok-i-lied-one-more-update/?do=findComment&comment=1511150 You can check it out for yourself. I opened it up and had a look, but I'm not sure what I would need to change. Edit: Looks like it might be the code I had before I added pushing the fire button to start the game. Unfortunately I don't think I have the later code on my computer any more.
  11. 1 - Why, to cram more code in, of course. 2 - I see what you're saying. I'll give it a try. Thanks.
  12. 1 - Good point, but I'm not quite sure how I would use the 4 cycles at the end of the scanline. Although I guess it would be good to play around until I found something that worked. 2 - I need DEX where it is because if X isn't 0 then I need to fill PF0 & PF1 for the next scanline. And I am using a form of SkipDraw. If I go the traditional rout which uses 18 cycles I'll have to do with STA COLUPF what I did with the left side PF0 & PF1. Which wouldn't be too bad actually.
  13. I wrote a program that only displays a single color sprite on an asymmetrical, multicolor playfield (the background is a single color). It doesn't do anything else, but that's fine because that's all I want it to do. I'm just curious if anybody has any tips or advice for writing the code to look a little neater, or have any optimizations that could squeeze out an extra cycle or two in the scanline code. Or if there's anything I could, or should do differently. If any of you decide to look over the code, then here a few notes first: It's a 1SLK. I came up with a sprite display routine that only uses 14 cycles instead of 18. The drawback is the Y register is devoted solely to the sprite. It can't be used for anything else (unless some cycles can be freed up. Each scanline is 75 cycles). In order to get the timing right the left side PF0 and PF1 are set before the first scanline, and then within the scanline they're set at the end to be displayed on the next scanline. I know some of you don't like too many comments, so I'm letting you know that I commented the hell out of my routine. Anyway, if you choose to look at it, thank you. Program.zip
  14. I'm embarrassed to say, I forgot the reset vector in my original program too. So I put it in....and I have an image! I knew it was something simple that I goofed up on. Thank you very much guys. I really appreciate it.
  15. Reset/Brk vectors - Oops, I forgot that bit of code. Thanks for reminding me. Compiling: I'm actually using 2 IDEs. For jEdit I have dasm $n -f3 -v0 -s$c.sym -l$c.lst -o$c.bin For Crimson Editor I have the arguments: "$(FilePath)" -f3 -o"$(FileTitle).bin" -l"$(FileTitle).lst" -s"$(FileTitle).sym"
  16. To make a long story short, nothing I do seems to work when trying to write code to display pixels. DASM creates a list file that looks fine, but the bin files doesn't work (Stella displays a black screen & alt-L shows 0 scanlines). To simplify things I created a program that clears all of the RAM, and then writes a pattern of %10101010 to the PF0, PF1, and PF2 registers. DASM creates a good list file but the bin is 0 bytes. At this point I'm frustrated both because I tried a lot of different fixes, and I KNOW the problem is a very small and simple one that I'm overlooking. So please, tell me what's wrong with this test program, so I can use the knowledge to fix my actual program. Thanks. P.S. I got so paranoid I took out all of the comments seeing if that would help . It's pretty simple so you shouldn't need them, but of course I'll answer any questions if something isn't clear. processor 6502 include ".\includes\vcs.h" include ".\includes\macro.h" SEG Code ORG $F000 ldx #FF lda #0 Clear STA 0,X DEX BNE Clear LDX #$EE STX COLUPF Frame_Loop LDA #0 STA VBLANK LDA #2 STA VSYNC STA WSYNC STA WSYNC STA WSYNC LDA #0 STA VSYNC ldx #37 VB_Loop STA WSYNC DEX BNE VB_Loop LDX #0 DrawLoop LDA #%10101010 STA PF0 STA PF1 STA PF2 STA WSYNC INX CPX #192 BNE DrawLoop Overscan LDA #%01000010 STA VBLANK LDX #30 Overscan_Loop STA WSYNC DEX BNE Overscan_Loop JMP Frame_Loop
  17. jbs30000


    Yeah, the last program I was working on uses sprite positions to check for collisions. So has there been any DPC+ kernel updates lately, or will there be? Just curious.
  18. jbs30000


    I guess session 25 is the only one that's new. OK, and as for collisions, that last time I played around I had to use sprite locations to detect virtual sprite collisions (and that should be sprites 2-9 instead of 2-5, my mistake). One last question then. When was the last time the DPC+ kernel was updated? The last time I did anything with bB was about 8 months ago.
  19. jbs30000


    Actually, I was thinking of the DPC+ kernel. It's just been so long I forgot the name. And I have played around with assembly. I did the tutorials from Andrew Davie. Although searching, I see he's done more lately. Anyway, is collision detection on the DPC+ kernel still buggy for sprites 2 - 5? Thank you.
  20. jbs30000


    Has there been any upgrades lately? Mainly, with the asymmetrical multiplayer kernel can you check for collision(player1, player5)? It's been over a year since I've done anything and it didn't really work, but I heard it was being worked on. Thanks.
  21. When I played around I finally had to just check the X and Y locations of each sprite to determine a collision. Unless there was an update, and I haven't seen any posts saying there was, then detecting collisions with sprites 2 - 9 isn't completed yet. This works in the "d" version. However, you have to assign colors for each player separately. They can share the same bit data, but not the same color data. Let me know if that's not clear. Of course it's clear.
  22. Thank you! May I ask you some questions? 1. Is it too difficult (i.e. is it challenging or frustrating)? If so, which part(s) did you find too difficult? 2. Did you play all three levels? 1. I didn't try very long. I downloaded it shortly before I had to go to bed. But for now I'm thinking it's probably the right level of difficulty and it won't take too long to get use to it. 2. No, I only made it up the stairs on the first level.
  23. Wow, that's really, really good. Very difficult too.
  • Create New...