eshu

This is quite impressive - are there any spacing issues, or could it be used to display a 128x200 bitmap? Unfortunately there are some spacing issues - Three player objects (6 characters) are 1-pixel out of place for a bitmap display on every other scanline. With the cycles gained by using DPC+ it would probably be possible to fill the gaps with missiles or the ball, like I did in another thread which was based on similar techniques - http://www.atariage.com/forums/topic/181816-bigger-bitmaps-with-dpc/. I'm pretty sure with bus stuffing (http://www.atariage.com/forums/topic/183085-bus-stuffing-like-the-graduate/) it should be possible to do a full screen (160x200) interlace display.

Finally found it - not the same at all but a similar trick: http://www.biglist.com/lists/stella/archives/200103/msg00127.html

Someone did it about 10+ years ago on the stella list, but I can't for the life of me find the post...... Edit: actually I'm not sure they were changing the sprites - I definitely remember a demo with a bunch of russian doll looking sprites that could be different colours, and it was done with playfield behind inverted player objects.

To add to what others have said - I've not actually programmed for the NES but compared to other 8-bits I've programmed on the small amount of RAM on the 2600 can make for a very different environment.

working perfectly for me

629: 630: 631: 632: I can't seem to cause the issue at other zoom levels.

Resolution: 1600x900 Pal Roms: Height 746 or 753 fixes the issue - it starts on 750 NTSC Roms: Height 632 or 629 fixes the issue - it starts on 630 Width doesn't seem to fix the issue.

Ah but they won't move vertically on that screen will they. This is what attracted me to attempting an RPG on the 2600 - graphically it's very suited to the kind of vertical seperation of screen regions that works very well on the 2600. Next up on my agenda is the overworld kernel, where the player is represented by the ball object like in Adventure/Dragonstomper - this leaves all the other objects free to draw the scenery. A similar sprite to the one used in the battle screens will move vertically in some of the indoor kernels, but again often vertical seperation will make it possible to have other graphics share the same objects, so for instance I'm expecting to have shops as indoor scenes, but the shopkeeper will be behind a counter which prevents the player and shopkeeper from occupying the same scanlines.

The issue didn't appear again until I disabled scanline interpolation - and disappears with intensity 0.

I'm in the very early stages of working on the poison chalice that is a new RPG for the 2600 - I don't get a lot of time to work on it so this ones a slow burner.....

I've realised PAL roms are differently effected - thought that might help you get to the bottom of the issue:

That last snapshot was at 20%, but the effect becomes much more pronounced if I turn scanlines up, so I think that's the culprit. Once again just have to say how awesome this is - can't wait for the final build of 3.7! Scanlines at 100%: Edit to add snapshot

Here's the issue on a more standard ROM. My videocard is a Nvidia NVS 4200M

The effect is most pronounced on the left hand side about 2/3 down from the top of the screen. It only shows up when 3x is selected for zoom and effects all roms I've tested, and effects all options except filter off, in both windowed and full-screen mode.

This is looking great as expected - Thanks for making the test build available..... I think there may be an issue when running with a zoom setting different than 2x - I get some weird artifacts that don't look like they belong, I'm guessing it might be using the 2x hardcoded somewhere by accident? Edit: actually 4x zoom looks fine to, just 3x has the problem - let me know if you want screenshots

This comment is wrong, I think. Otherwise it would simply be identical to a NTSC 2600. The difference is the location of the colour signal in the TV output. It's PAL. So the colours are PAL-centric. Numbering of colours is different between PAL and NTSC so my best-guess is that yes, NTSC carts will work just fine -- but they will be the wrong colours. Boulder Dash, on the other hand (when the switches are configured to PAL-60) actually produces the PAL colour numbers and the NTSC frame-rate. In other words, it's perfect PAL-M compatible. Other NTSC cartridges are not. Cheers A From the "Items for Atari 2600 manufactured in Brazil" thread - http://www.atariage....ured-in-brazil/

looking great! - I can't wait

I think what solidcorp meant was you need to reposition objects every line to get the venetian blind effect, but I wouldn't really call it a 1-line kernel. It's more like two 8-line kernels which you alternate between each frame. The reason I'd call it an 8-line kernel is because there is no loop within those 8-lines, because you need to access the bitmap data as quickly as possible you set it up in memory and then over those eight lines it is stored into GRP0 and GRP1 at the appropriate times. Here's a screenshot of one frame, so you can see a little better how i t works. Nope afraid not, and theres another wire muncher on the way to - although hopefully we'll move somewhere with more space sooner rather than later and I'll be able to set up the 2600 again, with a CRT TV and everything.....

I managed to get 32 characters working with venetian blinds flicker a while back - http://www.atariage....ost__p__2281086 I've never actually seen it running on a real 2600, but Omegamatrix's photo made it look like it worked pretty well on a CRT

Just have to say I think this has turned out really well, it looks like it's selling like hotcakes! $6,000 and counting! It's gone from a sales model that I really didn't like to an interesting new one - I wonder if any other homebrew authors will be tempted to follow suit? I just noticed this section: Something I definitely support - I think it's easy for developers to forget how much they depend on some of the excelent tools that have been developed over recent years, and it's great that Stella and Stephen will benefit from this, so a big +1 to scott from me.

Although I'm not involved with the project and don't endorse or condemn it, I can answer this part. Just because something is placed on the same CD as Stella doesn't mean that something has to released under the GPL. The only why the GPL enters into things is if it were somehow coded into Stella itself. For example, if the ROM code were put inside the Stella codebase, then it would have to be released under the GPL too. That won't be the case here, I assume. No worries - I find this stuff quite confusing. fwiw - this is the part that got me: You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. What I missed was: In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. Glad I don't have to deal with any of this licensing stuff!

Won't distributing it with Stella mean it has to be GPL?

Sheesh - the TIA has a LOT of colours for a system from this time! (More than the SMS or NES) See: http://en.wikipedia....onsole_palettes

A few different I think: LDA $1FEE NOP $1FEE LDA $1FEE,Y They could all be NOPS - but I started off using LDA and then needed to preserve all registers at one point so it uses an illegal NOP BTW: I'm really looking forward to Stella with blaarg filters, so don't want you to look at this 'til that's released but I mentioned to you a while ago about a bug in debugger mode when codes running out of zero page - you can see that here, the sprite drawing and bottom menu bar code both run out of zero page and theres a weird bug where the debugger doesn't seem to see the high byte of addresses being accessed by LDA $ABS,Y.

For some reason, your ROM is coming out at 65534 bytes, which is two bytes shy of a full 64K (65536). I suggest looking at the compiler options used and see if you can generate a full 64K. That way, there's a good chance the autodetection in Stella will set this as EFSC for you automatically. ahhh cool - i'll take a look when i get a chance - i'm just using the standard -f3 on dasm