.PLAN: Potatohead
potatohead
Posts: 10,261
(cluttered thread. Once I saw where it was going, it made better sense to put it here.)
Well, in that vein: (Not gonna do the fancy text editing though)
Current work:
1. Working on getting a multi-spirte engine, developed on AA, up and running. A fellow forum member ended up on a thought code project, based on a few propeller posts of mine. I think the result of that is gonna be decent (~25 active sprites per line, high-color, 3-5 cogs), so debugging that code and getting it out with a demo is what I'm working on right now. He did some heavy lifting that deserves some attention, IMHO. It's a unique design with each cogs video generator, drawing it's own scanline, thus cutting down on the amount of communication required between cogs and hub. Can adapt to higher color schemes too.
2. Color. I've posted one high-color demo here that's good for 96 colors. About 30 of them are very high saturation, the remainder are lower saturation. Needs color lookup scheme in COG to make programming easier. I will take some time at some point and over drive the video generator to put two pixels into one NTSC color clock. That's very likely to produce over 200 colors. Plenty. It's mostly CardboardGurus easy NTSC driver. That work cracked the nut for me as it's color clocks are aligned vertically, unlike the Parallax driver. At some point, I'm gonna go back through that one and add the higher color capability because the interlaced color looks great at higher resolutions. (above 256 pixels) Very classic C64 and NES looking. Would look great for text and line art games as well.
3. Display generation. IMHO, crafting a display scheme that maps to ones game, is very likely the best overall use of RAM. I've worked up, 160x96, 160x192 displays in high-color. I'll work through the timing of a few more, then start on character modes. This is where one byte of display memory, maybe two to deal with colors, map to an 8x8 cell on screen, drawn from a lookup table in RAM. Ideally then, things like score, status, lives, etc... can all exist in a fairly shallow area of RAM, leaving remaning display elements as bitmap or sprites, depending. Given the level of complexity full on sprites require, I'm leaning toward just doing software sprites and keeping the display high-color or maybe a fair number of colors with a lookup table.
These need to be combined to form a custom display. Haven't done that just yet. Just timing though, that's it. It's a push-pull between learning what I need to for the mixed mode displays and debugging the sprite engine mentioned above. If I've got long periods of time, I'll debug, shorter ones, I'll work on a display technique prototype, or combining existing ones. These simpler tasks also help with assembly language learning. I'm really getting there were understanding the instructions and passing parameters is concerned. Not so there where crafting larger projects is concerned.
Where I'm headed and some introduction:
At some point, the game I want to port over is Star Raiders. I dug out the old A400 and played this for a while over the holiday weekend. It's an excellent title with very high playability over time. Graphically, it can take good advantage of the techniques I mentioned above and uses keyboard and game controller at the same time. This is the first game that made me say "WOW". It's a perfect fit for the prop, IMHO. I come back to play this game every few years and it's never gotten old. Visually, it's getting up there, but gameplay is spot on and relevant today.
I also want to do a few 2600 style games. Simple, fast graphics with lots of color on the screen. The same display techniques will apply as that machine more or less demands the display kernel approach. That's the real reason for working on color, BTW. Gonna need to hook up a paddle, or rotary controller to the prop because the simple paddle games are where the appeal for me is here. KABOOM! Warlords, Super Breakout, etc...
I've only written simpler games in the past on the old A400 in a mix of BASIC and assembly. (SR will be a challenge for me, but worth it.) Most recent was the game Ooze! This was written in the Batari Basic langage for Atari 2600. Damn cool, and also something I would like to see running on the prop, but doing this it's beyond me at the moment. Maybe later as skill grows. I entered the Ooze! game into the 2006 minigame compo and had a lot of fun reading through the constructive feedback.
I've been out of programming and electronics for a long time. This little chip was the final straw for me. Just couldn't resist. So here I am, getting back into it and having a lot of fun. My last serious programming project was a 3D STL file viewer (viewstl) written on an SGI, to learn something about OpenGL. Ported to win32 and Linux later on. The multi-processor aspect of the prop is difficult, but lots of fun for me. I really enjoy working through this aspect of computing in that thinking differently pays off huge most of the time. Working through this stuff is fun, but practical too. Since it's modern hardware, that's gonna be in production for a while, I can apply the skills in other places down the road. Great stuff.
At some point, it would be fantastic to either involve the prop in the compo (problematic because most judges use emulation, not hardware), or have something similar get started for the prop community. Make it fit into 32k, one load to RAM, that's it. Anyone with any kind or prop, up and running, could participate. That was an excellent experience and one I'm inclined to repeat, from time to time.
Epmoyer: Arrgh! I won't be able to order the SRAM card until next month! After reading the manual, it appears totally doable to build a 160-320 horizontal full-on double buffered bitmap display with that thing. At the 160, one can have one byte per pixel, meaning the ability to take advantage of any color scheme developed so far. Higher resolutions will drop to 32 or 16 colors, but still damn nice. In that mode, software sprites drawn right to the inactive bitmap will look rock solid and likely be a lot less complex in that regular old school bitmap drawing techniques can be used instead of on the fly display generation. Maybe we will see something like ROBOTRON result from that.
Well, in that vein: (Not gonna do the fancy text editing though)
Current work:
1. Working on getting a multi-spirte engine, developed on AA, up and running. A fellow forum member ended up on a thought code project, based on a few propeller posts of mine. I think the result of that is gonna be decent (~25 active sprites per line, high-color, 3-5 cogs), so debugging that code and getting it out with a demo is what I'm working on right now. He did some heavy lifting that deserves some attention, IMHO. It's a unique design with each cogs video generator, drawing it's own scanline, thus cutting down on the amount of communication required between cogs and hub. Can adapt to higher color schemes too.
2. Color. I've posted one high-color demo here that's good for 96 colors. About 30 of them are very high saturation, the remainder are lower saturation. Needs color lookup scheme in COG to make programming easier. I will take some time at some point and over drive the video generator to put two pixels into one NTSC color clock. That's very likely to produce over 200 colors. Plenty. It's mostly CardboardGurus easy NTSC driver. That work cracked the nut for me as it's color clocks are aligned vertically, unlike the Parallax driver. At some point, I'm gonna go back through that one and add the higher color capability because the interlaced color looks great at higher resolutions. (above 256 pixels) Very classic C64 and NES looking. Would look great for text and line art games as well.
3. Display generation. IMHO, crafting a display scheme that maps to ones game, is very likely the best overall use of RAM. I've worked up, 160x96, 160x192 displays in high-color. I'll work through the timing of a few more, then start on character modes. This is where one byte of display memory, maybe two to deal with colors, map to an 8x8 cell on screen, drawn from a lookup table in RAM. Ideally then, things like score, status, lives, etc... can all exist in a fairly shallow area of RAM, leaving remaning display elements as bitmap or sprites, depending. Given the level of complexity full on sprites require, I'm leaning toward just doing software sprites and keeping the display high-color or maybe a fair number of colors with a lookup table.
These need to be combined to form a custom display. Haven't done that just yet. Just timing though, that's it. It's a push-pull between learning what I need to for the mixed mode displays and debugging the sprite engine mentioned above. If I've got long periods of time, I'll debug, shorter ones, I'll work on a display technique prototype, or combining existing ones. These simpler tasks also help with assembly language learning. I'm really getting there were understanding the instructions and passing parameters is concerned. Not so there where crafting larger projects is concerned.
Where I'm headed and some introduction:
At some point, the game I want to port over is Star Raiders. I dug out the old A400 and played this for a while over the holiday weekend. It's an excellent title with very high playability over time. Graphically, it can take good advantage of the techniques I mentioned above and uses keyboard and game controller at the same time. This is the first game that made me say "WOW". It's a perfect fit for the prop, IMHO. I come back to play this game every few years and it's never gotten old. Visually, it's getting up there, but gameplay is spot on and relevant today.
I also want to do a few 2600 style games. Simple, fast graphics with lots of color on the screen. The same display techniques will apply as that machine more or less demands the display kernel approach. That's the real reason for working on color, BTW. Gonna need to hook up a paddle, or rotary controller to the prop because the simple paddle games are where the appeal for me is here. KABOOM! Warlords, Super Breakout, etc...
I've only written simpler games in the past on the old A400 in a mix of BASIC and assembly. (SR will be a challenge for me, but worth it.) Most recent was the game Ooze! This was written in the Batari Basic langage for Atari 2600. Damn cool, and also something I would like to see running on the prop, but doing this it's beyond me at the moment. Maybe later as skill grows. I entered the Ooze! game into the 2006 minigame compo and had a lot of fun reading through the constructive feedback.
I've been out of programming and electronics for a long time. This little chip was the final straw for me. Just couldn't resist. So here I am, getting back into it and having a lot of fun. My last serious programming project was a 3D STL file viewer (viewstl) written on an SGI, to learn something about OpenGL. Ported to win32 and Linux later on. The multi-processor aspect of the prop is difficult, but lots of fun for me. I really enjoy working through this aspect of computing in that thinking differently pays off huge most of the time. Working through this stuff is fun, but practical too. Since it's modern hardware, that's gonna be in production for a while, I can apply the skills in other places down the road. Great stuff.
At some point, it would be fantastic to either involve the prop in the compo (problematic because most judges use emulation, not hardware), or have something similar get started for the prop community. Make it fit into 32k, one load to RAM, that's it. Anyone with any kind or prop, up and running, could participate. That was an excellent experience and one I'm inclined to repeat, from time to time.
Epmoyer: Arrgh! I won't be able to order the SRAM card until next month! After reading the manual, it appears totally doable to build a 160-320 horizontal full-on double buffered bitmap display with that thing. At the 160, one can have one byte per pixel, meaning the ability to take advantage of any color scheme developed so far. Higher resolutions will drop to 32 or 16 colors, but still damn nice. In that mode, software sprites drawn right to the inactive bitmap will look rock solid and likely be a lot less complex in that regular old school bitmap drawing techniques can be used instead of on the fly display generation. Maybe we will see something like ROBOTRON result from that.
Comments
5 c=1:x=160/2:y=190/2
10 graphics (160, 190)
20 clearscreen
30 setcolor 0, 10, 15
40 color c
50 dir = gamepad(0)
60 if (dir=RIGHT) then x=x+1
70 if (dir=LEFT) then x=x-1
80 if (dir=UP) then y=y-1
90 if (dir=DOWN) then y=y+1
100 plot x,y
110 if (dir = BUTTONA) then c=c+1:if c>3 then c=1
120 goto 50
If newbie people could code in a basic with graphics, sound, screen I/O, support for load/save to the eeprom, plus support for the sram that would do the trick. The basic we made in ASM is a good start, but the developer Robert has very little time these days with work etc. So as a first cut, someone should take femto basic and connect it to graphics, sounds, IO, the SRAM, and maybe redo the editor to make it a full screen editor that is more flexible than the line oriented one right now.
Andre'
IMHO, a compiled basic would not be a bad start either. There is some serious nostalga about programming right on the chip though. Perhaps one day we would see the interactive mode with a split screen graphics text display. Nothing beats that for working through core concepts.
Essentially, we need RAM to make good use of this technique beyond just being able to pick a subset of colors from a larger palette, or we need creative display schemes involving tiles, compression, etc... So, when I can get an SRAM, I'll continue this work to build a high-resolution bitmap display. Might be really useful for things other than games too. If one were to build a display indicator screen, with this method running in 320x192 mode, it would look really sharp. I fear the SRAM might not have the speed necessary to really handle some games. It's early though, so who knows. This bugger surprises me regularly.
Interlaced color, for the full 320 dots horizontal. I think this is just a simple code and timing change. Odd frames get one sync, even frames get another, or perhaps just set the counter to a specific value, output a small pixel, etc... For some games, this might be worth doing, even if it does not include the high color option. Square pixels look good on a lot of newer stuff.
Multiple COGs rendering the same scanline at the same time will yield more intensity levels, that do not need to be artifacted and or dithered. The memory mapping is a bear, but maybe worth doing for data display and not games. I'm thinking of rjo's greyscale question. Since the generators or together, perhaps a nice high intensity mono display might be possible. Having only 6 intensities is a real limitation for some display problems. This could open up a wider palette too, but only for more static displays where graphical speed is not an issue. (single buffered, etc..)
Essentially, this is NTSC overlay graphics. So I think I'm gonna go there, while the multi-cog sprite drawing engine continues it's journey to actually running. What I'm thinking is to minimize memory consumption, have a nicely colored display. The Atari machines had a display list function that was pretty cool. Essentially, there is a list of data that calls out how the display will act vertically. One could choose graphics modes (resolution, color depth, blank line, character / tile mode, etc...), memory addresses) on a scan line basis. This breaks the screen up into vertical segments, each doing their thing. Maybe just full on tiles makes better sense, but I like the linear and easy addressing that would come with the display list idea.
The overlay, using two video generators really does not quite act like a sprite, but how bad that is depends on what is being done. For some games, with black backgrounds, or fairly regular areas of color, it might just work slick, without having to deal with so much logic in processing. Careful color selection might go a long way toward making useful images. Another aspect of this could be very useful for static displays as well. Lay out the core display elements, however it makes sense and would consume the least RAM. Maybe stuff this into the SRAM, then make the variable elements of the display available as an overlay, that runs out of local propeller memory. From there it's just about picking sane colors in a fashion similar to how the cursor is done in Chips' high resolution VGA with cursor driver.
First step is to sync up two cogs, then draw some simple things to the screen, using the standard Propeller color palette. For overall ease of exploration, I'll start with just two bitmaps and go from there. Next will be a low resolution, but high color bitmap, with finer detail lower color depth objects in the overlay, positioned with timing, instead of a bitmap.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 7/23/2007 5:11:40 PM GMT
The two are sharing the same set of pins, for the overlay effect. Color timing is again an issue, but looks possible. I just need to think through the timing of the PLLs, and things should be golden. Monochrome overlay pixels appear to work nicely, so far.
Maybe post some code tonight --gotta get a capture device that will handle non-interlaced signals...
Here's a GEAR simulation (attached)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 7/23/2007 6:46:56 PM GMT
Do you have an intended application for this video trickery? Is it part of your quest for producing more colors from an unmodified Hydra?
I'm reminded of Elite, the BBC Micro game. It It used a split screen with different video modes. The top 3/4 of the screen was 320 pixels horizontal monocrhome. The bottom 1/4 was 160 pixels 4 color. The switch in screen modes was done with an interrupt on a timer started by the VSYNC. It took a couple of lines to do the change, so they displayed in black.
Of course with a prop you could do such split screens within a single cog. As each set of 1,2,4,8,16 or 32 pixels can have a different width. So you could do a split screen with the split vertical if you wanted.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
CardboardGuru, it's about a few things.
EDIT: Gear simulated it well enough. Capture attached.
At some point I want to port Star Raiders to this thing. It's my very favorite game and I think the prop would be a perfect fit. The Atari had mixed mode displays, similar to the one you linked to. I've already got that with just the one COG. Simply build the bitmap code, like it's being done in the driver I cleaned up, reference the line counter and break it into areas. That was why I did the work on the variable resolution bit. All the timings are the same, so one is free to do whatever makes sense on a given scanline. Vertical and horizontal areas are no biggie, given the VSCL stuff is computed and at the ready. That computer used a display list for dealing with that. One could just write a list with the vertical screen elements desired, then go. On the prop, a similar list could be used, but it's probably just as easy to just write the screen driver in the COG, for the game display planned. For this game, two COGs are the target. One for main background graphics, the other doing overlay sprites, etc... We agree!
I'm also eager to begin exploring the other aspect of this title. The game runs in real-time, with each element being modular. Enemies are running in one thread, graphics and user actions in another, objects in space, yet another. Seems a perfect fit for a few COG's all doing their thing. Seeing this title, long ago, got me into computing actually. There was nothing else like it, and it still plays very well today. Kept my old A400 just for that reason. I get it out once in a while and let the kids play as well. One person pilots the ship, the other mans the keyboard. Great fun.
This one can be keyboard / mouse or keyboard / game controller too.
Getting that Atari classic look is all about basing things off the 160 pixel NTSC color. Your Easy_NTSC work really helped me out big, in that regard. I've got to do a character mode next. Similar to tiles, but like the old computers did things. One puts a character set in RAM, then just specifies which one is to be displayed with bytes in the screen. Good for score, text, etc...
Once the character set stuff is done, I'll probably break the screen into two main chunks. A 160 resolution two scanlines high main screen (for lots of color, and the classic game look found on the original title), and a lower portion in character mode. Char mode will be 160, or maybe 256 x one scan line high, 8x8 cells. The overlay graphics will end up being used for semi-transparent HUD type displays. That will be an enhancement over what the old Atari did. Should end up looking cool --someday when I get the lower level graphics stuff nailed. This and the char mode are the last pieces of that. (then comes sound...)
Colors come into play too, but are not a focus. The resulting image is like an AND for sure. The two signals just add together with color largely depending on the intensities used. Bright pixels, being low saturation look more or less white. If the intensities are dim, then the color tends to blend together, giving a brighter colored pixel on top of a colored background look. IMHO, more grey scales will be possible, if that's something one wants to do. Maybe 12 shades, without artifacting --just the signals adding together. If one wanted more than the 400 or so colors I've put up, this technique would easily double that number, but addressing would be a PITA, or lots of bit banging in the COGs would have to happen, making it a multi-cog affair. Mix in the high-sat colors and one hell of a CLUT, and 10 bit color (mostly) could be done with the reference video circuits. I'm not going to bother though. Maybe the 512K makes sense, but a 32K prop doesn't.
One biggie is special effects. On the Star Raiders port, some of these things really could play into the game well and provide an experience unique to the prop. Getting the ship damaged, taking a hit, etc.. could really be emphasized by tweaking the actual signal --very cool simulation. An overlay plane would do the tinted shields up effect, forcing the player to look through the shield and it's tint on everything in the viewer window. A crack in the screen works the same way. Just put it up there and it overlays for free. Shields could have holes, etc... where the player can actually see clear space and needs to avoid that area, etc... don't know what elements make sense yet, just know they are possible.
Edit: I've attached a screen shot from the original game. It shows the resolution split, and HUD. On the Atari, hardware sprites, with overlay / underlay bits were used to make the HUD and shield display appear semi-transparent. That computer had enough colors to just do that kind of thing, with well chosen palettes. With the prop doing real overlays, there is a lot of potential to entertain here. The bottom portion of the screen is character mode. In this example, it's all 160 pixels, just a scan line height change, from a driver perspective.
It's an aspect of this chip that's unique. That brings with it some coolness potential worth exploring. IMHO, some game titles could be done this way, and avoid all the bit mashing required to merge sprites together. A black background would just allow all the COG's doing display to just draw where they will with no worries about what overlaps what. Underwater games could draw to a bitmap in the usual way, then overlay water, with a single color bitmap, or 4 color one, etc... Think ROBOTRON with transparency happening between COGs for free. Overlapping images would color blend, but nobody would care. If one were doing a first person game, or perhaps big scroller, having a HUD would be more or less free. Just overlay it where it makes sense and pick decent colors for it --done.
Practical applications would include a hardware like cursor (so long as it's nice and bright), for GUI's. Chip did this on his VGA driver. With VGA it's really easy. Just count cycles, or use waitvids to locate the cursor, then output it when it makes sense.
I've had this idea since I got my prop, but it's taken me a while to grok all the little details. Right now, it runs, but the PLLs are not synced. Got the COG's working together no problem. That's cake now. For this test, I duped the hi-color video driver, modified it to look for a counter value and to handle a parameter page, so multiple screen buffer addresses can be passed. (I still had a fair amount of trouble with this!) A few restarts later and the PLLs settled close enough to play with the video. Now it looks like I've gotta dig into the counters more and get them doing the same things at the same time.
A quick hack, suppressed the sync on the secondary cog. I simply directed the video output to a different pin group by default, then switched it to the active pins, right as the user scanline begins, in what you call the active display area. Seems to work well. The best thing to do is setup timing loops, based on clocks, and get rid of the sync code totally. Once I get the PLL's playing ball regularly, I'll probably do that to avoid the ugly consumption of pins for my benefit.
I would have posted it, but I really need to deal with the PLLs first. Ugly screen to something cool ratio is about 4/5 right now. ugh... People with older displays might not appreciate what can happen display wise. I got more than one *pop* from the guinea pig, obtained from thrifty, display I'm torturing right now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 9/18/2007 2:39:37 PM GMT
This is the video overlay 1.0. Pixel sync is done --or at least I think it's done. Need to try on a few props to see if the pixels line up. I've PM'ed a coupla people. If you want to run this, go ahead. Let me know if the pixels in the corner line up or not, and if you see tearing.
EDIT: No tearing, but also no joy yet on the more important pixel sync. Back to the cooker this one goes!
(thanks to those that tested for me)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 9/20/2007 8:51:45 AM GMT
I'm excited to see some two layer graphic drivers.
Thanks!~
--Andrew Arsenault.
Timing on that is tough. Thought I would punt for a bit, work on the character mode driver, then come back to it. It's totally doable. I've had excellent dual resolution color displays happen. It's just tough to make consistent. I suspect my initial timing strategy is not up to the task. That is what it always is with Prop video...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
My propeller work is on hold, and has been for a while. It's a combination of life and work dishing me some serious smack! I'm powering through both a professional and personal move to new locations, and I've got some sick and older people in tow. The upside is that when it's resolved I'll be in fairly solid financial shape, and that's not the case right now. Medical costs have taken their toll and it's time to live smaller and get people healthy again, so that's exactly what I'm doing.
Another upside is that I appear just fine, so this is just work that hit and that demands attention. It will all be over soon enough, leaving me to continue forward with the stuff I've got in process:
-KABOOM!
-Licensing on 8x8 NTSC driver code for obex
-Material for HYDRA book
It's great to check in here, from time to time and see it all still happening. Know I've got serious prop time envy everyone!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Take care, from me and I'm sure, all on the forum.
Catch ya soon,
Baggers.
PS, been quiet myself too, getting GFX lite finished to get it out the door, and work, and yesterday morning my laptop finally died [noparse]:([/noparse], it doesn't even want to turn on, it just keeps resetting after a few seconds ;(
So just migrating everything to a new ( YUCKY ) Vista laptop, god I hate Vista, don't know why you can't buy an XP laptop anymore [noparse]:([/noparse] lol
Can't even get my hotmail cos there's no outlook express [noparse]:([/noparse] but that's another story lol.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
You shoulda gone to misco matey, they have loads of XP laptops there
Good to see you are still around Potatohead, I was wondering if you and Cardboardguru had headed off into the sunset together lol
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
It's KILLING ME --absolutely, but what has to be done, has do be done.
Back soon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Heater has done amazing things with CPU emulation. I plan to build on that work to get 6502 to a running state. That plan has not changed, but after grinding through some tough stuff, I need a bit of joy! Call it just a break. I'm not letting this one go. With the overlay bit, I saw over time that it wouldn't matter. 6502 matters.
There are a coupla distractions. One will be mentioned here soon. (and it's cool, and it involves KABOOM and a Prop.)
Another is the Color Computer 3. It's capable of some great NTSC color, and I never documented it, and you all know I love squeezing colors outta things. Just got done doing that. Should have done it 15 years ago, when I discovered it, and was rendering fractals and other things with it. (Yes, the thing will do artifact colors like a Propeller does and that means 160x200x256 colors on composite video for that little box!!) Showing the color strips is cool, but a picture or some other nice demo might spark emulator support, and or at least put the matter to rest, so I'm hacking on that enough to get some attention there. The CoCo is one of those platforms that never quite got the love, but has a lot of power and solid user support still.
In any case, somebody had told me that color deal wouldn't work, so... you know what happens then! I bought one of the damn things, and posted it up working. God, I feel better! Been nagging at me for a month or so. And well, now I have a Color Computer again! Sweet! Someday, a Propeller and a Color Computer 3 need to be married. Would be sweet. (An edit to clarify this)
I've officially ditched overlay for the time being. It's kind of a niche thing that won't see serious use until Prop II. I originally thought it might make sense, but the evolution of graphics drivers really do render that kind of useless, IMHO. Besides, without doing color directly, al-a Eric Ball method, it's damn near impossible to accomplish. On Prop II, if the discussion threads here play out, overlay will be worth another pass. This is a feature unique to the Propeller and something to be exploited at some point. (Wondering if our friend Linus isn't doing this with VGA at Breakpoint?)
Speaking of that, doing NTSC color directly, using just VGA mode to output pixel data while ignoring the built in color circuits, leads to impressive results. Watch for a great driver coming soon. I love the idea, and from what I've seen, eye popping Propeller colors are possible. Looks great. I'm thinking I want to port over my text mode drivers. Would be worth the effort. No screenie yet!! Just hype. Let Eric do his thing!
That's it. Just thought I would take a moment and update the .plan. At this point, I'm the only one, but I like .plan and always have. So, there you go.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 4/6/2009 3:17:10 PM GMT
I wish I had more time at the mo, but with E3 looming, I'm pretty much full on with work [noparse]:([/noparse]
I too should try and start a .plan/blog thing after E3. it's good to air some thoughts [noparse]:)[/noparse]
I too am looking forward to Linus' demo [noparse]:)[/noparse] and Eric's NTSC driver, I too was wanting to do something along those lines, but have been to busy to get the time, and yes, the colours would be amazing as we have 8 bits, and Rickard Gun
Get plenty of sleep and eat good food on your ramp up to E3!
Yeah, having a place to just put stuff out there is good. What I find is that either it's lost, if I don't express it (bummer), or somebody else sees it and goes off and does something (cool), or it's there for me at some point in the future. I get a lot from reading others that do this, why not then return the favor in like kind? There is another thing too. I'm probably quite typical of this crowd in that I've more ideas than I can follow through on. Managing time, family, WORK (particularly right now), and other things puts limits down. Man, if I were only 16 again! Few worries... So then, airing them is important, because one never knows what's going to align and spark interest. Better to have the choice than not.
I love the demoscene. Never really took off here in the States. Not sure why. Been following Atari VCS and 8bit for years, watching people squeeze more and more and more out of the old Jay Miner chipset. What I like about it is the dynamic displays are often timing locked and solid. There is a crispness to that I've always appreciated. It's rather easy to just dedicate RAM enough to double buffer, then just draw it all out. It's a lot harder to build a display dynamically, harder still to incorporate the display into the game, so the two are really one. VCS (Atari 2600) programmers do this every day. I think it's art...
In any case, the stuff I see happen every year is just amazing. And I'm seriously hoping "wild" ends up spawning a MCU scene, maybe broken down by chip family. We've got the older 8 bit hardware for a while yet, but eventually people are going to move on. (maybe not though!!) Adding the micros to the scene would keep the good art relevant. And with that would come a nice blending as people can build stuff to show off, and do it with simple parts available anywhere really. IMHO, that adds a dimension to the whole thing not really seen to date. The hard core has been about minimal hardware, and that usually means older hardware, and that's cool, but minimal goes hand in hand with micros, and the techniques are very useful and motivating. The trouble with older hardware is that it is simply old! Sometimes hard to obtain, hard to interface, and often comes with a layer of understanding that is kind of a bit of overhead.
On micros, that's true, but the understanding has a lot of relevance, and being able to see the demo, build the board, then tinker with the code is the essence of what the scene is about. We all know this, of course. I guess I'm saying that many, who follow the scene might not, or if they do, are not yet motivated or attracted to doing it. Maybe seeing micros there would further that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 4/6/2009 3:34:22 PM GMT
Yes, don't worry, I will be getting plenty of sleep before E3 mayhem, and I always try to eat well [noparse]:)[/noparse]
Will have to keep this reply a bit short, as tea time is looming, and I'm trying to get the animation side of the re-write done today lol
I know what you mean about having to get access to older computers, where-as it's a lot easier and cheaper to get a prop kit, with prop plug, which then gives you the ability to program it, not only that but it's a far nicer language, than the older computers. [noparse]:D[/noparse] and with all the objects in obex, it's a great starting point for anyone to jump aboard. it would be nice to see some more demo coders getting onto the prop. especially from the retro scene, as it's perfect for the job.
anyways, I best get back to this before tea. lol
(BTW, something off topic, I just had to share, lol, my wife is looking for a new HDMI home cinema system for us, on amazon, and there was a panasonic system with a 250KG hard drive, even had her in bulk, saying that must be a big drive weighing that much lol [noparse]:)[/noparse] )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·