Andrew Davie
-
Posts
5,982 -
Joined
-
Last visited
-
Days Won
8
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by Andrew Davie
-
-
Is this game going to be showing up in the AA store?
A quick count shows 58 still unclaimed. Given that Christmas is still a fair way off, I would expect that all 200 would be claimed by then. It's possible that some will make it to the store, but I may very well buy all the leftovers myself and flog them on eBay at grossly inflated prices
Cheers
A
-
Most requested is two 3-digit scores. It's not perfect, as the two scores are on the extreme left and right of the screen, and I don't think there is any other way to pull this off.
Not so! Refer to
showing 3-digit scores not at extreme edges. This bit of trickery from Thomas Jentzsch. -
I wanted to confirm that the bugs #2 and #3 are NOT fixed.
Good stuff, thanks. I've copied this to the [dasm-discuss] mailing list. It would be really great if you guys could join that list, as cutting and pasting bug reports from this forum is hardly an ideal way to operate!
Cheers
A
-
What new features exist for 2600 programmers?
Please join the [dasm-discuss] mailing list where these and other questions are being answered!
Cheers
A
-
From DASM maintainers:
"We just released the first update to DASM in 4 years, DASM 2.20.11! A lot of things are new about this release, including a slightly more Unix-oriented distribution (that can still be built in Windows). Several bugs have been fixed, several features have been added, see the extensive NEWS and ChangeLog files for details. We hope this release will convince everybody that DASM is alive and kicking. "
What new features exist for 2600 programmers? Will it still (try to) produce a 4+gig binary on something like:
org $7FF8 byte 1,2,3,4,5 ds $7FFC-* byte 1,2,3,4
Using org rather than ds might have been more convenient, except that it would put org and rorg out of sync.
I've been toying with the idea of making some changes to DASM, but didn't particularly want to encourage the development of code that wouldn't work on older versions. Still, if the thing is being maintained and people do want new features, it might be neat to add some:
-1- An option to allocate two memory buffers of a requested size; the first would hold an image of the program being built, while the second would indicate which areas of memory have been used (the free-space map would not necessarily require a second memory buffer, but that would be the easiest way to implement it). Allow .org's to go out of sequence, provided that no area of memory is written more than once (a "ds" should skip over memory without writing it, to allow for back-patching).
-2- A syntax to allow label names to be derived from labels values and/or numerical expressions. For example, something like:
mac stackless_call mov x,#sc_count jmp {1} ret_{{sc_count}} = * sc_count .set sec_count+1 endm mac sc_rets: SC_RET_LSB: temp .set 0 repeat sc_count db <ret_{{temp}} temp .set temp+1 repend SC_RET_MSB: temp .set 0 repeat sc_count db >ret_{{temp}} temp .set temp+1 rependI've managed to kludge something similar using Roman-ish numerals in labels (forty-nine is xxxxviiii) but the listing file for even a small program is outrageously huge. Do you know any nice way to do anything like the above?
These sorts of comments are very welcome, and we have a mailing list attached to the SourceForge project just for this purpose. Not all DASM developers are Atari-based, and will not notice your comments here at AtariAge. I've posted a copy of your post to the list, and I would encourage everyone interested in DASM improvements to join and contribute to the [dasm-discuss] list, available through the SourceForge link mentioned earlier.
Cheers
A
-
Yay! But how come it is not posted here?
DASM has been moved to SourceForge and a new maintainer, Peter H. Fröhlich, has taken over the reins. Peter's put some rigour into the maintenance and methodology of DASM releases and bug fixes, and it's quite clear the tool is now in very good hands. So, the atari2600.org site is soon to disappear. With a SourceForge project, we can all have input to the fixes, there's announcement and discusion mailing lists, and bugs will be fixed much much quicker.
Cheers
A
-
From DASM maintainers:
"We just released the first update to DASM in 4 years, DASM 2.20.11! A lot of things are new about this release, including a slightly more Unix-oriented distribution (that can still be built in Windows). Several bugs have been fixed, several features have been added, see the extensive NEWS and ChangeLog files for details. We hope this release will convince everybody that DASM is alive and kicking. "
-
I am just loving this! I'm actually able to learn assembly after years of being stuck with BASIC...and it's for the 2600! If it's alright with Andrew...I might use this code in the start of my first game program for the 2600. I like it...it's clean.
Also...would doing away with all of the spaces between lines in an assembly source code be ok...or are the spaces there for a reason? Can't wait to see how to do sprites and sounds! ON TO THE NEXT LESSON!
Go for it, make a fortune!
The spaces between lines are purely a style issue. I have it, you don't... yet
Remove those, if you wish.
Cheers
A
-
Yeah, why shouldn't southpaws (like me) be plagued with an awful controller? Why should righties have none of the fun? We lefties deserve misery too!
...or we could just regret that there was one made for righties in the first place...
I was fortunate enough to use the prototype powerglove. The thing about this device is that it has (had) two modes. One mode, a "gesture" mode, had pre-programmed movements you could make which would then return a simple joystick direction. So, for example, you lift your arm up and down, and you get joystick "up" sent. The problem with this is that there's significant lag between when you start the gesture, and when it's finished/recognised. Not a great control system at all.
However, there's a second, 'raw' mode. This mode had 1/16th of an inch accuracy over a 6 foot range (all this is from memory, of course, but I'm pretty sure). This reported the actual position of the glove in real time. That allows the application itself to do all the nice trickery. It's actually quite an interesting, GOOD device. It was just hamstrung by having to use gesture mode for the NES game backward compatibility.
So, don't 'diss' the powerglove, because you clearly don't know much about it
Cheers
A
-
Qb kicks major @$$ for sure!
How did the game get named "Qb" anyways? I have some ideas but they aren't pretty.
Cube-y
Played on cubes.
Cheers
A
-
It is likely that this particular Qb is an unauthorised copy/fake. Please check with me first if you want to ascertain the authenticity of such items.
-
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewIt...E:IT&ih=006
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewIt...E:IT&ih=006
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewIt...E:IT&ih=006
international shipping, paypal accepted, shipping to USA: 6 Euro
Was this Qb purchased from Hozer recently? Within, say, 3 years?
Cheers
A
-
I'm just curious if anyone has contacted FSS about this project, and what their responce was(if there was one).
All is being done with FSS's approval. Everything I do is OK'd with them first. Our communications have been friendly and I think we both hope to bring the project to a successful release. I have been (on and off) in discussions with them for over 5 years now, so we have a long history during which time I think we have established some trust and understanding. I have to solve a few technical issues to get the game to function perfectly, and I'm not putting any pressure on myself to do this. It's finished when it's finished, and at that time if FSS approves of the final result then it will be released. There are no fundamental showstoppers regarding permission or copyright; these have been sorted out.
Cheers
A
-
I have typically kept in-progress binaries and videos of the work I have done. it's quite interesting to see the stages of development, and look back at the failed experiments and dead-end ideas. i would be quite happy to contribute videos showing such progressions, if wanted. Boulder Dash ® in particular has some very interesting early demos showing quite clearly the genesis of the systems. I think someone needs to point out the way that the hardware works, particularly with reference to drawing a TV frame -- this is half the attraction.... isn't it??
The documentary is a great idea -- but keep it to half an hour -- short and sweet -- and who knows, it might be on TV one day
Cheers
A
-
Hi! It was some time ago, but this was my attempt (back in 2005) using Paul Slocums music kit v2.0.
Regards,
Moderntimes99
To my limited music/sound capabilities, this sounds pretty good. I do recall a thread about the sound somewhere; I will have to find it and see what was done back then. Does this music kit only require one call per frame?
Cheers
A
-
I've known for some time, of course, that 4A50 offers opportunities for improvement in the capabilities of the engine. I've just been a bit frightened of it
My first attempt at doing a converstion was in March 2006. I know these things because I actually comment my code 
but of course I abandoned this when it didn't work. Tonight I restored that old attempt, ripped out everything BD-related (for of course, it's all out of date anyway) and just went back to basics -- a flashing colour background. And voila, I have a working 4A50 binary. Now I plan to have a think about the layout I want to use for a bit, while slowly adding in bits of the game to see how it all comes along. -
I think your comments and demo are very interesting, and sobering, but wish you'd go and find another project to bully!!!
Besides, I've been trying to bully him for years to use character pairs.
Especially since 4A50 would allow the lookups to be done in-kernel.Give me a good price on 4a50 boards! I do acknowledge the advantages of the format, but making the move is a bit daunting.
-
As an experiment I tried seeing what the gfx would look like with only 2 alternating colour lines, rather than 3. The 21 pixel height of the 'tiles' doesn't quite fit here, but this is just a mockup.
Well, although this might look better when full size on a TV (due to less spacing between the colour line effect), it's missing the wider range of your colour palette, especially the grey as well as the blue for the boulders. Still, it was an interesting experiment..
I find the smaller the TV, and the further away you are, the better BD looks. I don't mind this, really -- back in the day, smaller TVs would generally be the norm. Your experiment is interesting, and I'm sure could be used for other games requiring just a 4 colour playfield. It's a bit un-nerving seeing these runnable demos using the exact graphics that BD uses; in principle these graphics are copyright © First Star Software... so perhaps it might be worthwhile keeping that in mind. I'd like to keep them happy.
Cheers
A
-
I'd guess it would work well to change one scan line of the diamonds per frame (i.e. running the code once). Figure five frames of adding a 'red' pixel to the diamonds (which would otherwise be green+blue), then five frames of removing a red pixel, etc. That would make all the diamonds shimmer at 6Hz. Doing that would add about 700 cycles/frame overhead. Not trivial, but hardly outrageous. The biggest caveat would be that when drawing diamonds one would need to be careful to draw them in the correct state. That would be balanced, however, by the fact that one would not have to redraw them for purposes of animation.
An interesting idea I'll keep in mind. A similar thing could be used for amoeba animation. But it's a fairly radical change, so not high on my list of priorities, and the cost is kind of daunting.
-
The diamonds look much better in blue, regardless of the shape. I'm glad I could help contribute in some small way.
By the way Andrew, I noticed in this video:
That the boulder fall mechanics seem to be a bit wrong in the last part of the clip. They seem to move to the right off of a falling boulder? I thought in the originals they only bounced left or right of a stationary wall, diamond or boulder?
Yes, the boulder mechanics are currently a bit odd because the objects are not processed in the same order as in the original. This is a quirk of the techniques I use to get good speed out of the system, and not a permanent issue. There's a missing "sort" that I am currently working on which will fix this problem.
Cheers
A
-
Went to all that work, thought I'd share.
And a nice effort it is, too! I'm quite impressed. However, I don't believe predefining all tile pairs is the way to go. TJ and I considered this and it does restrict things somewhat with the number of tiles possible. The current system is a bit more general-purpose. I think your comments and demo are very interesting, and sobering, but wish you'd go and find another project to bully!!!
Here's the current character count...
2 PF variants x
( blank / soil / rock / diamond(2) / butterfly(2) / firefly(2) / explosion(3) / amoeba(2) / wall/magic wall (4) / steel wall )
and that's for BD#1. I expect that if this engine were to be used for further BD variants then predefined pairs become more untenable. TJ and I have discussed using predefined pairs for only common variants (eg: soil/boulder) and this might happen.
-
9 x 9 tile-pairs = 81 x 2 copies for PF1 vs. PF2 = 162 x 21 bytes per tile-pair = 3402 bytes. Easily fit in a bank.
4 different tile sets, doubled for 2-frame animation = 8 banks. That's pretty huge, but you're already at least that big, right? Since you're using 1 bank per row?
Only one 1K bank per row, not 4K bank.
Cheers
A
-
It doesn't lag, it's "speed challenged".
Andrew I think what you are saying is that you built such a superhuman game it pushes the TIA and 6507 beyond all limits, and that it actually is not slowing down but speeding up so fast that the rest of the universe is struggling to match its velocity, correct?
Close. Because BD uses the 6507 much more than most games -- instead of EVER waiting for timers, etc., it uses ALL available processing time as much as possible to do the stuff that needs doing. So the 6507 runs much hotter than it would in most other games. And we all know, of course, that the hotter elecronics run, the slower things get. So what's happening is that the more efficient the game is in terms of optimal use of the processor, the slower the Atari actually runs. So the game slows down. It's a balance, you see. Simple physics, but not many people understand this stuff as well as me.
Cheers
A
-
And for each of the 21 lines per character row, would it not be faster if you did a check to see if that line had any gfx and then skipped if not? For example, the earth gfx only uses the orange scan lines, the new diamonds only use blue and white and air doesn't use any lines at all.
You may do something like this already, which is why I asked. If so, I wonder if like with the diamonds it's possible to optimise the enemy colours to save time?
No, it wouldn't be faster. You still have to erase what was there before. This is achieved by copying the entire new character in, even if it consists of stripes of colour.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Back To The Future!
in Classic Console Discussion
Posted
Hey Anthony, this game was programmed by a friend of mine named Trevor Nuridin. He works at Tantalus Interactive these days. I remember it being programmed, as I sat at a nearby. desk.
Cheers
A