Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by jum

  1. Jum, it seems that you are about to finisch Chopper X? :)



    Yes, it has to be finished before the June deadline for the multicart.


    But it will be finished way before that, so I can do some fine-tuning/polishing on it to make sure it works 100% slick on a real Lynx.

  2. Progress on Chopper X:


    Rebased the code for compiling with "new" cc65 2.11 (big mission, also had to rewrite the audio code), replaced tgi stuff with custom functions, design of stages 2, 3, 4 almost completed.


    TODO: flip, pause, escape/quit, etc. Some simple tunes. Polishing and tweaking.


    Note: ChopperX is made to run in 64k



    - jum

  3. My Lynx I has some dead pixels, and the power jack is loose.


    Other than that it still works fine after 12/13 years (even after hacking the screen into a slide projector and then reassembling)...


    Store in a cool dry place, preferably in a box with those little silica packets.


    My favourite games are the simpler ones like Calfornia Games and Klax. There are more impressive games, but I think handhelds are more suited to simpler "pick-up-and-play" games.

  4. Wow, great improvements! The ship controls very nicely. The deformable landscape works really well and is a very cool effect. The anti-aliasing on the ship is a nice touch.


    I'm looking forward to seeing this turn into a real game. It's very interesting to be able to follow it's progress.



    Hey thanks :)


    Personally I think the ship is a bit "wide", and also I'm unsure about a graphical style / look to use. But I'm not going to get bogged down in graphics.


    What's more important is:

    1. Ideas for levels (320 x 512 pixels, made from 16x16 tiles)

    2. Ideas for "enemies" (besides ufo's and gun turrets)


    Any suggestions are welcome.


    I'll keep updating as I progress...


    - jum


    PS: yes it's possible to crash into your own particles, especially if you're moving fast and then turn quickly. It's a bug.

  5. see new version at beginning of thread.


    sage: I can do assembler if I have to. Please email or post your asm source for putpixel.




    - jum


    ps: I have since done the 32 sprites for the ship rotation (actually, 8 sprites that are flipped horizontally or vertically as needed (thank you Lynx designers :) ).

  6. update: I have now switched to using a 320x512 1 bitplane unpacked sprite for the background, and have made setpixel and getpixel routines that read and write to the sprite.


    now busy with creating 32 animation frames for the ship rotation. also need to speed up the setpixel/getpixel routines.


    - jum

  7. The channel select switch is for VHF channels 2 and 3 in the US. I don't recall the exact frequencies but you can probably find them in a Google search. If the switch is gone it might default to one of the channels but I'm not sure. You might try to find a switch to put in there just to verify.


    OK, I just a Google search myself and it looks like channel 2 is at 55.25MHz and channel 3 is at 61.25MHz. I hope that helps.





    Thanks Mitch


    It looks like the open switch selects one of the channels. I'll try to retune.


    - jum

  8. No I'm not in the good ol' US, but my small LCD TV handles NTSC/PAL/whatever.


    I've done a full "program scan" on my TV, and only found the 5200 "signal" at one place in the VHF and UHF bands.


    What does the "channel switch" on the back of the 5200 do anyway (ie: which channels/frequencies does it select)?

  9. I'm having another attempt at getting my 2-port 5200 working.


    Symptoms: snowy screen at power on, maybe faint vertical bars behind snow.


    Also the "channel switch" at the back of the 5200 is missing/removed (switch is "open").


    Also I'm powering it thru a 220 to 110 VAC stepdown to the 5200 power brick. My TV is auto PAL/NTSC.


    Also I replaced VR1 and VR2 (3905's) because they had been ripped off in transit.


    After taking a look at the 5200 Field Service troubleshooting chart, it seems that the problem could be a faulty RF modulator. I check GND on pin 1 and +5V on pin3 and they seem OK (0V and 4.93 V).


    If the problem is the RF modulator, then I'd be happy to make a composite video mod.


    However, before I go to that trouble, I want to make sure that the video output is the only fault in this machine.


    Is there an easy way to tell if there are other faults?


    Will tapping into the audio output help me determine if the machine is actually running a game?


    Any help appreciated.


    Thanks - jum

  10. I used the "setpixel/getpixel on unpacked sprite" in my ChopperX game, for the scrolling terrain (320x50 sprite).


    I was trying to avoid losing cycles to large sprites, but on the other hand a 300x300 "virtual background" would suit this game better.


    Do you still have the source code to your Tron game?

  11. This may help you (from my Jum52 source code):


    for(i = 0; i < 0x4000; i++) mapper = MAPPER_RAM; // RAM

    for(i = 0x4000; i < 0xC000; i++) mapper = MAPPER_ROM; // CART

    for(i = 0xF800; i < 0x10000; i++) mapper = MAPPER_ROM; // BIOS

    for(i = 0xC000; i < 0xC100; i++) mapper = MAPPER_GTIA; // GTIA

    for(i = 0xD400;i < 0xD500; i++) mapper = MAPPER_ANTIC; // ANTIC

    for(i = 0xE800;i < 0xE900; i++) mapper = MAPPER_POKEY; // POKEY

    for(i = 0xEB00;i < 0xEC00; i++) mapper = MAPPER_POKEY; // POKEY (mirror)


    - jum

  12. Very nice, keep on going, this could become a really cool game.


    You are using a lot of memory with the large buffer, but with this you are saving on screen redraw, which leaves you extra system power to do neat effects with.


    You could speed up getpixel and setpixel by using a multiplication table (y*80) instead of the <<6 and <<4 you're using now.


    calc_ship_verts could be sped up by not using generic sin and cos tables but premultiplying them to give the right distance from the center of the ship.


    I see you are already using mean(?) (point1+point2)/2 values to create extra interpolation points with little calculation cost.  You could also interpolate from the bottom two points to the center of the ship, for a nice spaceship shape.


    Programming the Lynx in C looks nice BTW, I've been using ASM, which is fast but cumbersome.


    Your game is inspiring to look at.



    Thanks for your input man.


    I'm not concentrating on optimising right now (rather get some good gameplay first), but if you would like to write a fast ship-drawing routine in asm, please do, and I will integrate it into the source code.


    I can only work out the correct "scaling" of the sin/cos tables once I've figured out whether I need to use 8:8 fixed point or 10:6 or whatever. Also I'm going to cut the sin/cos tables from 256 values to 64 values.


    - jum

  13. I need the 160x306 buffer because (like spout), I want to be able to blast the walls/landscape with the thrust blast.


    I've locked the framerate to 20fps now. It's maybe a bit sluggish, but at least it doesn't slow down and speed up all the time. I'll post a new version soon.

  14. The source code is in (low-level) C. If you want it email me: <removed>


    I was thinking of combining a gravitar-type game with "spout" (ie: no fire button, you use your thrust jet to destroy enemies).


    Also I'm undecided on whether to implement using vector gfx (raw lines and dots) as it is now, or whether to use sprites.


    Yeah the 2600 gravitar is impressive.


    - jum

  15. here's a preview of a gravitar or spout type game I'm messing with.


    press X to thrust.


    any gameplay ideas welcome.


    - jum


    Updated 2005-10-07: uploaded a new version (james1.zip). See what u think.

    Updated 2005-11-24: another new version which uses scrolling bg sprite to make a much larger "cave"

    Updated 2005-12-05: updated wip version with tilemapped bg sprite and animated ufo.


  • Create New...