cmcmanis%pepper@Sun.COM (Chuck McManis) (08/14/88)
In article <4989@pasteur.Berkeley.EDU> (Herbert West) writes: > I figured if they are doing it, why don't I? I have three LOFlists > and look for the 0180++ loads just like they do, and don't even call > LoadRGB4(). I have to do it on each list, of course. Herbert, if you insist on doing this it will bite you in the behind the minute they (being the people who own the code you are going "around") change the way things work. In a hack it can pass, but if you plan on selling this game I'll bet you money that it breaks in 1.4 and then all of your customers will be pissed off, and they'll be pissed off at you! It is never reasonable to "go around" the system provided interface like this. >David Ashley --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
dale@boing.UUCP (Dale Luck) (08/14/88)
In article <4989@pasteur.Berkeley.EDU> koster@cory.Berkeley.EDU (Herbert West) writes: > >I figured if they are doing it, why don't I? I have three LOFlists >and look for the 0180++ loads just like they do, and don't even call >LoadRGB4(). I have to do it on each list, of course. Mimicing what the OS currently is doing is a sure way of increasing your chances of that game not running on future versions of the OS. If you are looking for 0180's in the copper list and then succesively loading your own colors you may fail on future versions. There may be a reason that I need to load the colors in reverse order, or if I ever get my way and get a multiple move copper instruction, you bet I will use it. Assuming the system copper lists are going to remain in their current format is not a good idea. Revving your game when a new release breaks it may seem to be a good solution however it is cbm that get's the blame for being the bad guy for releasing an incompatible version. I suggest you take over the machine and build your own copperlists from scratch. We are committed to provide register level compatibility in the hardware for future chip versions. > > >koster@cory.berkeley.edu >David Ashley -- Dale Luck Boing, Inc. {cbmvax|oliveb|pyramid}|!amiga!boing!dale Although I do contract work for Amiga-LosGatos, my opinions probably don't represent those of Commodore or its management or its engineers, but I think the world would be a better place if they did.
jimm@amiga.UUCP (Jim Mackraz) (08/16/88)
In article <4989@pasteur.Berkeley.EDU> koster@cory.Berkeley.EDU (Herbert West) writes:
)I had this problem that with double buffering, each LOFlist had its own
)color load-up set, so LoadRGB4() only worked on the last LOFlist and not
)the other ones.
)
)I tried various honest things, then decided just to look at the ROM and see
)what they do. I single stepped the LoadRGB4() routine, and what did I find?
)They modify an existing in-use Copper list on the fly!
)
)They look through the LOFlist and find copper load instructions to the
)0180++ range for the color table, then write the next word.
)
I don't really want to join the long list of people warning you that
you'll blow up if the copper lists the OS creates ever change in format,
but I thought of another problem you might have.
)I figured if they are doing it, why don't I? I have three LOFlists
)and look for the 0180++ loads just like they do, and don't even call
)LoadRGB4(). I have to do it on each list, of course.
The reason is that use of the system screen copper lists is arbitrated by
Intuition, so that if you allow the user to drag screens, hit AmigaM/N,
or a system requester pops a screen to the front, Intuition will FreeMem()
the copper lists (or maybe it's FreeVPortCopLists or something). Unless
your are protected against this, you is busted, big-time, this release.
Now if you are protected against this, your only sin is assuming something
about the format of the copper lists created by MakeVPort().
Now, I don't know why you needed to change colors so often, nor some other
things about your requirements, but if you can, you might want to prepare
two viewports, and two views, and double-buffer using LoadView(). This
is 'least overhead' (near-optimal) and you can just call LoadRGB4()
on both viewports.
Now if you really are going to assume the format of the copper lists, and
protect against them being freed, you only need to search once, and as I
tried to suggest in some mail (might have bounced), you might even consider
using the blitter to copy the color map portion of copper lists around.
But indeed, you better make it clear that you will possible need an upgrade
in the future, and that such problems will be yer fault. You won't be the
first, but if you can use the system calls, or protect yourself from
system changes (such as by cobbling your own copper lists which are
copies of the V1.2 copper lists maybe), it would be better.
)koster@cory.berkeley.edu
)David Ashley
--
Jim Mackraz, I and I Computing
amiga!jimm BIX:jmackraz
Opinions are my own. Comments regarding the Amiga operating system, and
all others, are not to be taken as Commodore official policy.haitex@pnet01.cts.com (Wade Bickel) (08/16/88)
cmcmanis%pepper@Sun.COM (Chuck McManis) writes: >In article <4989@pasteur.Berkeley.EDU> (Herbert West) writes: >> I figured if they are doing it, why don't I? I have three LOFlists >> and look for the 0180++ loads just like they do, and don't even call >> LoadRGB4(). I have to do it on each list, of course. > >Herbert, if you insist on doing this it will bite you in the behind the >minute they (being the people who own the code you are going "around") >change the way things work. In a hack it can pass, but if you plan on >selling this game I'll bet you money that it breaks in 1.4 and then all >of your customers will be pissed off, and they'll be pissed off at you! >It is never reasonable to "go around" the system provided interface >like this. > >>David Ashley > >--Chuck McManis Hi Chuck, If we need to accomplish something NOW and it can not be done without going around the system, and the Amiga Guru's who are changing that system won't give specific information about how it is going to work in the future (for which I don't blame them, I wan't them to have the freedom to revise earlier decisions as they actually tackle specifics), WHATS A PROGRAMMER TO DO? I think that 1.4 is far enough away that worring too much about it now (as far as games are concerned) is probably a mistake. Lots of things are going to break on 1.4 anyway, so people will be used to needing updates. I'm not saying that one should fiddle with the system routines if they can avoid it, but if there is no other way... What I suggest is that anyone implementing such a hack think about the fact that it will need updateing in the future. Arrange things so a patch can be made available, or at the very least so that the whole program will not need rewriting. It seems 1.4 will be a substantial improvement, so everone will be scrambling to gererate updates to take advantage of the new features as well. As I understand it the controllability of the copperlists will be much better in 1.4. Thanks, Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
cmcmanis%pepper@Sun.COM (Chuck McManis) (08/17/88)
In article <3317@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: > If we need to accomplish something NOW and it can not be done without >going around the system, and the Amiga Guru's who are changing that system >won't give specific information about how it is going to work in the future >(for which I don't blame them, I wan't them to have the freedom to revise >earlier decisions as they actually tackle specifics), > WHATS A PROGRAMMER TO DO? Well assuming the programmer is a registered developer, they give Commodore the low down on what they need to do and why they think they need to go around the system and say "Ok, this is what I need to do, and this is why it doesn't seem to work currently, and this is what I am considering doing about it. How can I do this an be supported in later releases?" Commodore will (by definition of Technical Support) provide either a solution or alternative suggestions that will accomplish what you want to do and be compatible with the future. That is their job. The stupidest thing a developer can do is hit a problem, and then blindly charge in and use some "inside information" like an entrypoint in the ROM or an undocumented data- structure to solve it and never tell anybody. Asking C/A accomplishes three things, one it raises their awareness of a weakness in the system that can be addressed in the next release. (Overscan is a good example of this in 1.4) Two, it lets them figure out how to support you both now *and* later without compromising the system's design. Three, any other developer that has the same problem gets a ready made solution. > I think that 1.4 is far enough away that worring too much about it > now (as far as games are concerned) is probably a mistake. Lots of things > are going to break on 1.4 anyway, so people will be used to needing updates. Wade, this is a Commodore-64 attitude and you should know it. 2.0 isn't far enough away that you shouldn't worry about it. If you are a professional you realize that the better you are at compatibility now the better your product will be in the future (and the more profitable). Not having to send updates to your product can be worth hundreds if not thousands of sales. That's money, and as a developer for the Amiga you should always strive to maximize the return on your investment so that you can continue to eat. > I'm not saying that one should fiddle with the system routines if >they can avoid it, but if there is no other way... And I'm saying there is *always* another way. And if there isn't then you can get Commodore to give you a workaround that they will *always* support. That's why there is a developer support program in the first place. > What I suggest is that anyone implementing such a hack think about > the fact that it will need updateing in the future. Arrange things so a > patch can be made available, or at the very least so that the whole program > will not need rewriting. What I suggest is that anyone writing Amiga programs for profit a) Become at least a registered developer ($50 to CATS, ask ...!cbmvax!lauren for more info) b) *use* that service to make their code as robust as possible. And if you are making a living writing code for the Amiga become a commercial developer. Then when you have these problems solve them *with* Commodore and everyone wins, your product still works under future revisions and the Amiga becomes more capable as it is extended to do what you needed it to do. (In Herbert/Dave's case you will notice that several alternatives were posted that solved his problem in a compatible fashion. This is almost *always* the outcome when you ask Commodore.) --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
lel@wuphys.UUCP (Lyle E. Levine) (08/18/88)
In article <4989@pasteur.Berkeley.EDU> koster@cory.Berkeley.EDU (Herbert West) writes: > >I am able to have over 10 small figures, about 12x12 each, displayed at >60 frames per second, and now have 32 colors. > Does this POPMAN game come with the source? If so, you might make quite a few more sales... ========== IBM is a Division of Sirius Cybernetics Corporation "their fundamental design flaws are completely hidden by their superficial design flaws." - "So Long And Thanks For All The Fish" Lyle Levine: Paths -> ihnp4!wuphys!lel Best way: (314)889-6379 uunet!wucs!wuphys!lel