NRV

Technically I suppose you can do that with all the "scanline" modes (I suppose that in gr.7 the pal "bleeding" also works, but only affects one scanline of the below pixel? (the top half).. too lazy to test x) ) Strange that it worked different in Altirra than Apac.. maybe if you select higher lumas? What do you mean with "without DLI constraints"?.. this should be worse than Apac because you need to change the 4 color registers every line.. not just PRIOR.. What happens if you alternate a "yellow" (top line) with a "red" (bottom line)? .. you get a yellow and an orange??.. and that orange "bleeds" over another line?? ..so many questions Regards.

Thank you, but as far as I understand the aproaches and the sources are very different: Quantizator works different than RastaConverter. And version numbers are totally different, too I think that RastaConverter is younger and looks better . (Because ilmenit has a lot of experience and the result is getting better each new generation) I can´t wait to have a look at the source of the new generation and to learn from that! I believe he was talking about this: http://www.atariage....ost__p__2504806 There is a link to rastaconverter 0.9 with source there.

Not necessarily, you could move any object in steps lower than "one pixel size" and base the speed of the object and the collision methods in this "decimal" steps. Of course for our 2:1 pixels the movement is going to look coarse in the horizontal directions, but the collision precision can be the same one that in the arcade version.. and that one is "char" based by the way (that's the reason of the "bug" where you can go through a ghost sometimes.. both objects change their "tile" position at the same time). All this info is in the Pac Man dossier: http://home.comcast....mandossier.html I have the original ghost behaviors, the collision methods and the pacman movement (with the classic speed up when taking corners, to outrun the ghosts) implemented according to that info.. maybe someday I will have the time to add the rest of the logic to put "arcade pac man" in some new mazes x)

I'm still a little confused about what is needed , but I suppose you mean v&(v-1) == 0 when v=2^x ? When v is not a power of 2, then the result is different than 0 (could be differents values.. well to be exact "the rightmost bit is cleared" from v).

I don't know how the blitter works, but.. To know if a value is a power of 2 (your eight values that need conversion) you can use: f = (v AND (v - 1)) .. if this is zero then is a power of 2 The problem is that zero is also a "power of 2" with this method.. maybe you can replace all zeroes with another value, like $FF, before doing this.. Then you can use something like f2 = f OR (f XOR $FF) to transform any non zero value to $FF And finally f3 = f2 XOR $FF to get the result in the format that you want.. If you can't use intermediate values maybe you can do more "passes" or use auxiliary buffers?

Emmm.. el quizo decir www.atariware.cl (no ataware..)

Nice, didn't know that you can use parameters with .REPT (I would have used # and #*2 directly in the inside). You can also use the iteration count # with the other format: :4 sta $2000+#*2 ==> sta $2000 sta $2002 sta $2004 sta $2006 Sometime ago I would have liked to nest .REPT statements, but I couldn't .. I don't know if it's possible now (but you can use the :n format inside a .REPT)

Adding a 75% and a 25% options is a little more work, but I will try. With the 25% option there are some positions that you are not going to be able to reach and the jitter could be more visible, but maybe is still not a big issue.. About the XL/XE you mean the paddles? or the memory?. At this point I'm using below 48K, but I'm disabling the OS, to use a custom NMI handler, so I suppose that discards 400/800 models.

Is good to know that they work well. Wow, for me 50% was already too fast . But I tested it only in the emulator. The problem is that with 50% there is already a 1:1 relationship between the paddle values and the pixels moved in the screen, so to go faster I must jump over some pixels. The thing that I can try is adding some acceleration, like with the mouse, configurable in the options. I agree, that one is a pain, also in the arcade . I don't want to change the rule that much, but I can do a special version of that level, a little easier. So if you see another levels that are too frustrating just send me the pictures (I normally avoid that screen ). Regards.

Thanks for the code Bryan. For now I just implemented the straightforward method (just using POT0..3 and POTGO). Here, version 1.81: pad_v6.zip Changelog: - first extra ball is at $20000 and then after every $100000 - added a small ball speed up when catching the "mega ball" powerup - when pressing RESET we do a cold start now - fixed: unable to select "arcade" after changing the difficulty - fixed: giving unwanted score when opening the exits at the end of a level - added paddle controllers from 1 to 4 (select with "C" option) - added "Paddle angle" option: 50% or 100% (use half or full rotation to move) - modified high score logic, so when you select easy, casual or arcade you see the score and level info for that difficulty only - added "highlight" effect for all hard bricks at the start of a level About the jitter issue, I suppose is both ways, maybe a problem with the 130xe, but also a problem (in time) with the paddles. I wait for any report about that, for people that play with real hardware. I tested the paddles using the mouse with Altirra and I use the 100% rotation option, because the other is too fast for me, but maybe in real hardware is not like that. The multiball not giving powerups for now is to clone the rule in Arkanoid 1, but also because I'm using all the players for the 3 balls . I'm still thinking about what to do ingame when passing the high score. In the next days I just want to add some "things" to the tittle screen and that new game mode that I was talking, and let this rest for some time . Regards!

Ooooops.. casual is there two times.. don't change arcade if you want to play that for now Ok, thanks. Do you know if is useful to sample the paddles many times in a frame and average the results? I would like to know how many times can the value change in a frame.. but probably in the editor the behavior is different.

+1 Hi! I have already working the 2nd port option for the controllers (press "C" to choose the controller and port now). I also added a "casual" difficulty mode that is easier than "arcade" (the starting speed, the max speed and the "touching-the-top" speed are one step lower, and the time that it takes the ball to speed up is 40 seconds, instead of 20). pad_v5.zip The only problem with this version is that the high score is for both, casual and arcade. I'm going to fix this soon. Right now there are 28 levels ordered in a "tree like" structure. You start from level 1a and you can choose to go to levels 2a or 2b (left or right exit at the end of the level). From 2a you can go to 3a or 3b. From 2b you can go to 3b or 3c. So, for the first level you have only one option, for the second 2, for the third 3 .. and for the seventh level you have 7 possible options. It's done like this so one play through doesn't take too much time and to give an "exploration" feeling to the game. Obviously there is probably only one branch that can give you the highest score and I tried to balance that with the difficulty of the branches. The game ends (you win and go back to the menu) when you complete the seventh level. I want to add another game mode with almost the same levels, but organized in 14 or 15 levels in two branches (left and right, like with arkanoid 2). I will try to add also one simple enemy to this one. About the powerups: many of the decisions about them are oriented to replicate the feeling of the arkanoid arcade games for now. I didn't wanted to introduce originals ideas yet, mostly because I didn't have much time to test them also, but I should say that the current system doesn't have a random element "that" big.. is true that the number of powerups generated can change a little between plays of the same level, but the principal factor of that is your play style, because the bricks that can generate powerups are fixed in every level (you can get this info for the Arkanoid 1 levels with a tool called ArkEdit) and the two most important rules for powerup generation are that: there is no powerup generated while there is another one falling and also when the multi ball is active. So the gameplay right now, if you want a high score, is oriented to get all the possible powerups, what adds a big "risk / reward" factor.. that I like. I like to think about the powerups as the "spice" of the levels, if not sometimes they are too plain and boring. I'm also pro a little random factor in some games, in between poker and chess I suppose . I added a rule to get a $5000 bonus score if passing the level without losing (I hope you read the scoring rules in the first post!). The "skip level" powerup can get you out of a difficult level and give you a bonus of $10000, but a real good player will try to advance that level till the end, without using the exits (what is very difficult), to score more points and get that $5000 bonus also. Yeah, I also prefer the mega ball to the laser (is more in the "spirit" of these games). I can make little adjusts and organize some special game modes if people want it, but I don't want to dedicate too much time to this project for now, because of another "priorities". That's why I don't want to implement combining powerups right now, but it can give you very interesting options, I agree (Arkanoid Returns does something like that... also Blasterball 3 did that well, but maybe the recomendation comes from too near ). Regards. (About the reset trapping.. should investigate a little, I'm not doing it on purpose, but I normally deactivate the OS and use all of page zero). (Going to look at paddle support also).

Looks like an easy and nice game

Not for now.. Thanks, I didn't remember that.. if someone request paddle controls I'm going to give it a try.

Hmmm .. the sequel? (Phobos) http://www.atarimania.de/detail_soft.php?VERSION_ID=3942&MENU=8

Let's guess! Hmmm.. bullet? A 2d shooter I say.. maybe a vertical one.. with no scrolling?

I like macros.. You can use :0 (parameter 0) to get the number of parameters passed, and use it to check for errors or select another code path inside your macro: ;-------------------------------------------------------------------------------- ; SetColor [0..4] [0..255] ; SetColor [0..4] [0..15] [0..15] ;-------------------------------------------------------------------------------- .macro SetColor .if :0 < 2 .or :0 > 3 .error "SetColor error" .else .if :0 = 2 lda #:2 sta COLPF0+:1 .else lda #[:2 * 16 + :3] sta COLPF0+:1 .endif .endif .endm You could compare a parameter (:1, :2, :3, ...) with 256 to see if it is a byte or a word, and do another code path.. ;-------------------------------------------------------------------------------- ; SetMemory [address] [bytes] [value] ;-------------------------------------------------------------------------------- ; warning, using some page zero memory .macro SetMemory setMemPtr = 254 setMemCounter = 252 .if :0 <> 3 .error "SetMemory error" .else ldy #0 lda #<:1 sta setMemPtr lda #>:1 sta setMemPtr+1 .if :2 < 256 lda #:3 setMemLoop1 sta (setMemPtr),y iny cpy #:2 bne setMemLoop1 .else lda #<:2 sta setMemCounter lda #>:2 sta setMemCounter+1 setMemLoop2 lda #:3 sta (setMemPtr),y iny bne setMemB1 inc setMemPtr+1 setMemB1 lda setMemCounter bne setMemB2 dec setMemCounter+1 setMemB2 dec setMemCounter lda setMemCounter ora setMemCounter+1 bne setMemLoop2 .endif .endif .endm You can use "string" parameters with %%1, %%2, %%3, ... like in: .macro ClearLine_ESC_M2_3bytes lda %%1+256*?zoneNum+32*:3+0,x sta %%2+256*?zoneNum+32*:3+0,x lda %%1+256*?zoneNum+32*:3+1,x sta %%2+256*?zoneNum+32*:3+1,x lda %%1+256*?zoneNum+32*:3+2,x sta %%2+256*?zoneNum+32*:3+2,x .endm StartESC_M2_3Bytes_SCR1 ?zoneNum = 0 .rept ZONES_OF_256_BYTES ; for the graphic mode ClearLine_ESC_M2_3bytes Background_01, DL1_memory, 0 ClearLine_ESC_M2_3bytes Background_01, DL1_memory, 1 ClearLine_ESC_M2_3bytes Background_01, DL1_memory, 2 ClearLine_ESC_M2_3bytes Background_01, DL1_memory, 3 ClearLine_ESC_M2_3bytes Background_01, DL1_memory, 4 ClearLine_ESC_M2_3bytes Background_01, DL1_memory, 5 ClearLine_ESC_M2_3bytes Background_01, DL1_memory, 6 ClearLine_ESC_M2_3bytes Background_01, DL1_memory, 7 ClearLine_ESC_M2_3bytes Background_01, DL1_memory, 8 ClearLine_ESC_M2_3bytes Background_01, DL1_memory, 9 ClearLine_ESC_M2_3bytes Background_01, DL1_memory, 10 ClearLine_ESC_M2_3bytes Background_01, DL1_memory, 11 ClearLine_ESC_M2_3bytes Background_01, DL1_memory, 12 ClearLine_ESC_M2_3bytes Background_01, DL1_memory, 13 ClearLine_ESC_M2_3bytes Background_01, DL1_memory, 14 ClearLine_ESC_M2_3bytes Background_01, DL1_memory, 15 rts ?zoneNum ++ .endr .. this is and old macro from a software sprite experiment, that also use a local var inside the macro (?zoneNUm)

I do not want to respond to the old thread linked here, however, what analmux has forgotten to mention is, that you can specify the Zeropage locations RMT-player should use. So the mentioned "$d1" is relative to the ZP-Start he supplied while assembling. Very true, but the page zero vars are: p_instrstable org *+2 p_trackslbstable org *+2 p_trackshbstable org *+2 p_song org *+2 ns org *+2 nr org *+2 nt org *+2 reg1 org *+1 reg2 org *+1 reg3 org *+1 tmp org *+1 and most of them are pointers, so it shouldn't be that difficult to log them and see. Also, I suppose that there is a default address for those vars.. that could help (for future reference, because probably Heaven doesn't need the info anymore ).

Some online tips: http://www.arcade-hi...=detail&id=2328 and the classic reference: http://en.wikipedia....28video_game%29

Yes, it does this automatically if you make the window big enough. Reducing the view region to standard or OS region only helps if the borders are too big to allow this to happen. Currently you can't fix the ratio or force the emulator to crop besides through the view region settings. Doh, I was almost sure to have tested that This controls how fast the mapping is from the host controller to the emulated controller, i.e. how fast the emulated mouse moves when you push the host joystick or mouse. Higher values move the mouse faster. There is a hardcoded throttle in the emulator to prevent the mouse from moving too rapidly, though -- it buffers movement so that the control lines only change at most once every 32 scan lines. Then if I want a 1:1 relation between the mapping I set it at "1"? (or the default value "5"?). I would like to simulate the feeling of using an atari mouse in the real hardware. Also, could this hard coded throttle be configurable at some point? Like setting it at 8 scan lines? I suppose that reading a mouse every 8 scan lines right now is just a waste of code time then. Regards.

The problem there is that If I did that (stagger the layout) the terrain wouldn't line up with each other (all four sections would be a pixel off). It would be more noticeable in the later parts of the maze where the 'buildings' go almost all the way up to the top of the screen. @godzillajoe: MESS doesn't show the issue properly. ProSystem does exactly what the actual hardware does in this case, which is stutter the movement of the entire playfield. It's very noticeable. @ ken: I will see if I can re-arrange memory to give this a try. Thanks, Bob I try, but I don't see a problem with Rybag's idea, but maybe that is because my background is mostly for the A8, not the 7800 . I don't get why all four sections would be a pixel off.. I could understand a char/byte.. but one pixel? I also tested your test file in prosystem and it looks really nice (from one that played scramble at the arcades).. I had a hard time finding the "stutter" and I believe many people will be happy to overlook it, if they can have this on a 7800 Anyway the method from Ken is like the standard for horizontal scrolling, a circular or ring buffer.. like in this classic image: Regards.

Isn't that what the "View -> Stretch Mode -> Integral Square Pixels" option does? I have two questions for Phaeron: - Is it possible to have integral square pixels with a multiplicator, like x2 or x3? (I think this was discussed before, sorry to ask again ). - What represents the "speed" parameter in "Add/Edit Input Mapping" for a mouse controller? Thanks.

Nice!, is good to know that the code supports a better mouse then. I know that there is a mouse speed parameter in Altirra, but I don't know exactly what it represents.. anyone have any info on that? Phaeron?

Your "AND (Ptr1),y" changes the content of the accumulator (A) only, doesn't write back the result to memory.. you still need to write the result of the operation with a "sta (Ptr1),y" .. is that your question? The only instructions that modify memory are sta, stx, sty, inc, dec, asl, lsr, rol, ror

From a fast look at that thread, it seems that is mostly the same that doing the work for one paddle.. in that case it is possible (and can be tested in Altirra). Maybe in version 1.8, but no promises Edit: Hmmmm.. but the manual says that you can put it "St-mouse" mode: "when pushing the left and right button while the middle button is pressed the interface is instructed to operate in ST mouse mode" It should already work then.. or am I wrong?