Atari 2600 Screen Editor with Code generation?

[lucienEn]

Hi, I started creating a screen editor that can generate assembler code based on screen contents (and validate in case not enough cycles to do that).

I wonder does this already exists before I spent more time on this?

This is work in progress and code generation hasn't been added, (NTSC) color selection, background and playfield editing plus load/save work.

 

Question: I noticed the coordinates shown in Stella differ from grabbing a snapshot: for example left corner of Pitfall is shown as: x=8, y=40. But taking a screenshot it shows as x=16, y = 17. The x difference makes sense since it's 2:1 ratio, but not sure why it takes 23 scanlines (instead of the full overscan area)?

[+splendidnut]

20 minutes ago, lucienEn said:

I wonder does this already exists before I spent more time on this?

Yes and no.

 

You can compare what you're doing with some of the graphics editing tools currently available:

 

 

 

20 minutes ago, lucienEn said:

Question: I noticed the coordinates shown in Stella differ from grabbing a snapshot: for example left corner of Pitfall is shown as: x=8, y=40. But taking a screenshot it shows as x=16, y = 17. The x difference makes sense since it's 2:1 ratio, but not sure why it takes 23 scanlines (instead of the full overscan area)?

The vertical portion of the television frame is under program control, there is no guarenteed standard for scanline positions.

 

[r_chase]

Honestly, I would be happy if this can generate code for batariBasic. One little question: will this be available on Linux?

Thanks for your work though.

[lucienEn]

39 minutes ago, splendidnut said:

Yes and no.

 

You can compare what you're doing with some of the graphics editing tools currently available:

 

 

 

The vertical portion of the television frame is under program control, there is no guarenteed standard for scanline positions.

 

The background builder looks interesting and has multiple kernel code macros, but nothing that brings it all together yet it seems in 1 screen. Not that that is necessarily always desired if only part of the screen is dynamic.

 

From what I observed Stella shows 250 total scanlines for the vertical blank (NTSC) in the debugger which makes sense. However when you save a screenshot it does: 14+192+22 = 228. I assume that is an arbitrary overscan removal based on what analog TV's typically show.

 

For the editor then I could use the safe area and show only scanlines 38..228

[+splendidnut]

15 minutes ago, lucienEn said:

The background builder looks interesting and has multiple kernel code macros, but nothing that brings it all together yet it seems in 1 screen. Not that that is necessarily always desired if only part of the screen is dynamic.

Indeed.  But, there are probably cases where being able to "stage" sprites/missiles/the ball might be really handy.  (for building / planning something like Pitfall as you've pictured)

 

 

In regards to scanlines, I believe 210 visible lines (game screen + score area) would cover most use-cases.  That would leave 52 scanlines for game logic/vysnc.  (Example breakdown: 3 vsync + 27 vblank + 22 overscan)

[+Dave C]

I use the background builder a lot but for sure I wind up using it to create mock-ups that I then need to adapt.

So one of the tricky things about using a tool is working on zone-based graphics, where different kernels are employed on different scanlines - I was just playing around with hacking abb to superimpose a grid that helps me see the zones I am using for my current project(s) as well as a "test sprite" to get the size constraints. 
 

[8bitPoet]

6 hours ago, lucienEn said:

I wonder does this already exists before I spent more time on this?

I haven't found anything as useful as this looks. I've had to mock up screens in Photoshop. This looks promising! I hope you'll continue to develop it.

[lucienEn]

17 hours ago, Dave C said:

I use the background builder a lot but for sure I wind up using it to create mock-ups that I then need to adapt.

So one of the tricky things about using a tool is working on zone-based graphics, where different kernels are employed on different scanlines - I was just playing around with hacking abb to superimpose a grid that helps me see the zones I am using for my current project(s) as well as a "test sprite" to get the size constraints. 
 

This is all early but I'm hopeful that when I start implementing code generation, it can automatically figure best way to efficiently split up in zones including how many kernel scanlines per object. Also in theory with adding ball/missiles it should be able to validate it will fit in 1 scanline or not and fail if not. But likely more complicated than I think it is:-). Worst case it won't be efficient and someone manually needs to do post processing on the ASM file. Either way will give it a try later when I have more time again to continue.

 

Right now background and playfield (repeat/reflective/asym.) painting are fully working including load/save/undo. Missing is ball & missiles but best to first try to add code generation.

[+Dave C]

3 hours ago, lucienEn said:

it can automatically figure best way to efficiently split up in zones including how many kernel scanlines per object.

So is there a way you identify which sprites (objects) can move where?  essentially deciding the ranges of vertical and horizontal motion determines when and where you would potentially need to reposition a sprite (unless you use a multisprite kernel like bb in which case you use one big zone for everything)

[lucienEn]

On 1/5/2023 at 11:23 AM, Dave C said:

So is there a way you identify which sprites (objects) can move where?  essentially deciding the ranges of vertical and horizontal motion determines when and where you would potentially need to reposition a sprite (unless you use a multisprite kernel like bb in which case you use one big zone for everything)

Yes I thought I could have an advanced sprite library editor where I can define the movement area and overlay that and it can figure out the kernels.

However that's bit much for now so will first try to get this working without player sprites. I'm thinking to have 'auto kernels ' wizard but allow with drawing operation to change the start lines. E.g. see below where you can auto-generate kernel blocks (it checks group of common actions per scanline and makes that 1 block) and use 'Kernels' to merge/add (it found in this case 7 kernels but I need to make that visually better):

Edited January 6 by lucienEn