LS_Dracon

As for optimization, have you thought about variable vertical resolution for PF? Some screens with buildings only, no diagonals or other details, can be made with 12 bytes only... Edit : Found 2 problems : 1 : Running and hitting the corner of the vertical exits, makes the screen jumps (randomly?) happens at bottom of the screen, also. 2 : The "hit spark" is bleeding in this area.

Congrats! Well, 2 and 3 actually, SynthCart is not a game I'm bad at writing reviews, sorry...

You don't really load them to memory, they always exist. What you do is change it's graphics (from existing data on BIOS, you can't personalize) and change it's position on screen. That's why you need to move them out of screen, you can't disable them individually (you can disable all of them at once, but this includes the sprites). Characters should not overlap each other, or it result into visual glitches and the game could crash. Even moving them out of screen, you need to worry about overlapping. Even if you set an "invisible" data (space) the bug happens. The conflict lies on X and Y position, not on what it's displaying. So games like Attack of Time Lord that uses most of characters moving around screen, very close each other and never overlaps, is an impressive feat! The sprites itself (4 available) are other objects, this one you actually load to memory a graphic data and can overlap/collide objects at will.

I don't know if this is the problem. Just a guess.

No, it's not related to the processor speed / timing. I think the problem is, you can't disable the chars, so you need to move them out of the screen, if you don't want to show on screen. PAL screen is bigger, so if you move the chars down to 240 pixels on NTSC they will not shown, but on PAL machines they will.

Thanks to Kevtris, now I know exactly the timing : Each scanline takes 22.75 processor cycles. This means if you to write 23 NOPs in a row, you skip a scanline. Note the .25 missing, there's no quarter cycle in a processor, so every 4 scanlines you lost a cycle, this means every 3 scanlines you need adjust the timing to 22 cycles only. The kernel is a loop of 23,23,23,22 cycles and repeat. The code works better if you set it after a timer interrupt, which starts more or less on the same position, every frame (it is not pixel perfect). In fact, according Kevtris, each processor cycle takes 10 pixels wide. The jagged black color on screen edges (see the tv picture above) is the missing .25 cycle on each scanline, and then when I remove a cycle it returns to original position. Edit : I'm talking about NTSC machines. I don' know the timing on PAL machines, yet.

Is this version programmed by J. J. Abrams?

If you're talking about the same system you posted pictures on other topic, it's indeed the original Odyssey. I would not mess with this system, it's probably the oldest with best condition console out there. Keep it inside the box. Don't throw anything out, keep the original plastics bags and rubber bands and if you want to sell it, doesn't matter much if all games are working because the great overall condition.

Edit : You're talking about the original Odyssey not the Odyssey2...

I wish the enemy was Mongul, would be much cooler, he is stronger than Superman, would makes sense in this plot (an enemy that needs more than 1 hero to defeat), and they would save the actual story we saw for later movies, with justice league set up and running. Lex could bring him to the Earth messing with the kriptonian tech, opening a portal or just make him interested to visit the Earth. Also no one would cares if was exactly like the comics or not. I liked the movie until the fight between Batman and Superman, then the movie was ruined to me.

I think a short jump would add a good difficult your game needs. It is difficult to jump over the enemies in the arcade, that's what you need learn to master the game. You can work with enemy collision tolerance to balance that. If your kernel support, you can use an indirect indexed addressing to point the ladder graphics to PF. Draw some blank lines below the ladder gfx, then adjust the pointer to "show" some of these blank lines. You can simulate the animation with few bytes. The game is great as that, BTW, it's just nitpicking.

You're right. I've played 3 loops and the game gets more difficult. The speed seems ok now, but I still thinking the "ladder climbing speed" should be slower. The spring on elevator level is too slow even after 3 loops. I think the speed do not change after the second loop? I miss the telescoping ladders on pie factory level. How about respawn the fire enemies some time after killing it with hammer?

Very good! I have some suggestions, if you don't mind: I would reduce a bit the PF color bright, because the flicker makes the sprites darker. If you kill the first fireball, can the barrels roll down that area? The game is too easy, can you make Mario walk slower? I think the same speed as the first fireball. Make him jumps shorter, also. On the elevator level, you can remove these PF pixels to avoid a jump that skips the elevator, see the image.

Odyssey 3 was renamed as Command Center before canceled. There is like, 2 or 3 existing prototypes in collector hands. G7400 is the same hardware with small changes on BIOS and a PAL tv compatible machine. The cool of it, some O2 games was codded to support the "high res" background from O3, so theoretically you plug the game on O3 and magically it looks better! With Z3k it could be real!

E-Paper? And have you any plans for Odyssey 3? Since you already have the core for Odyssey 2....

Brazilian consoles are NTSC compatible, both screen format and colors displayed, at 60 fps.

Odyssey 2 have this particular shape at bottom that prevent non Odyssey 2 carts to be plugged in.

That was a quick mock up I threw. My idea rely on pf pixel removed. It's more feasible to make the "bump" with ball. Or a missile with black color at bottom, then you don't need to remove the PF pixel. On either case the brick is rectangle, not curved. EDIT : Problem solved, using a "double hat". Hitting the corner still a minimal problem but I think it would looks acceptable. EDIT 2 : That is the iesposta ideia, I think .

Ok, first, download the latest version of Stella and stick with it. The best emulator by far. Javatari is a new emulator, a good one, but for play, not for develop a game. Second, you can use TIM64T for skip the scanlines during VBlank. It's needed as you can free the processor for calculate the game code while the timer take care of scanline timing. Make sure the game run at stable scanlines, on Stella, press "tab" key to enter in debug, and see the scanline count at top. Don't woirry about poor programming, you need start somewhere. Good luck.

Yes, I'll start with a code to copy the background data from ROM, stores on extra RAM, then set the variables to draw the screen. Later, the code for the floor bricks, then how to put enemies on screen, at this point I'll be able to build an entire level, although not working (enemies AI, traps, falling bricks, etc...) For background I'll use a nibble for each PF, so with 2 bytes I have information for PF1-PF2-PF2-PF1. 6 bytes per screen. I have an idea to animate the background for the falling bricks then I can display the pieces on the floor. It's needed as some switches require be activated by falling bricks.

Well, what I want already exist, it's the 3E bankswitch type. Now I have a 16k ROM full of nothing, I'll expand for 32kb when needed. Actually 3E allows me to easily expand both, ROM and RAM. A start for a long journey.

The original code is open source GPL3, except for the name (belongs to EA), you can call it as Micropolis (the open source version).

These tech demos are to display a specific part of the game, now we know it could work, I need to code the game itself, based on these experiments. As the sole programmer of the project now, I'm trying to find the best bankswitch type for it. After failed with F4SC (32 kb + 256 bytes of extra RAM) now I'm thinking to create a new ROM type based on Commavid's Video Life (1kb of extra RAM + 2 kb of ROM) but with possibility to bankswitch the 2kb of ROM. 1kb of RAM is overkill but if this makes the programming easier (and certainly will do), I don't care. I need about 400 bytes of extra RAM for the game, that's what I'm aiming. I've lost too much time coding the F4SC structure, and the data compression, which worked (it saved 800 bytes, almost 1kb of the prince graphics data) but makes everything too much difficult to code.

This looks good!

I know there's a guy making LDC screen replacement for GG and Lynx here.