Jump to content

PeteD

Members
  • Content Count

    1,748
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by PeteD

  1. The C64 one (at least Hawkeye did, pretty sure Flimbo is the same) just uses 4 charsets with the background parts pre-shifted (which is why there isn't a lot of variety in the background) and switches between them every frame. That's also why all the foreground "holes" are square, no mixing the back layer with the foreground chars. The other video with multiple levels and vertical movement, things get more complex.. Pete
  2. *sigh* Here we go again, can't handle a bit of truth, emkay gets himself into his usual spiral of "everything is better than the C64" and out come the thread lurkers to stir trouble. Us douche-tastic? I think you need to look closer to home
  3. That's a version, like the g2f ones posted here, of the C64 image, a port that's matched as closely as the machine could manage. The fact it doesn't do a great job can't be covered up with "the style is clearly more blue and ambient".
  4. Now you're a mind reader too. lol
  5. It's a decent attempt at a conversion, as Ste said. Unlike emkay I don't think the goblins look better in all green tones, the C64 ones may have been done like that because that was a standard colour set (brown to green) but all green removes any kind of idea of environmental light from them and makes them look dull. A funny side note, we don't "need" to convert it back to the C64, we already have a perfectly good one that's been around since mid 80s. I know what you're saying though and totally agree, the main point is each machine can do things the other can't. Attempting to do something from one machine on the other is (or can be) fun and I find tends to knock people out of their rut of maybe doing things the same way over and over, like trying to do pictures in same shades of a colour JUST because the machine can. Pete
  6. Should be even easier than on the C64. Not sure if the C64 has colour RAM scrolling though, I've got a feeling it does but the parallax scrolling itself is a simple routine. Pete
  7. Yep, nicely done Good to see more people producing quality images.
  8. Love Piesiu's stuff. He recently did a C64 picture that came 2nd at the Seilesia party. (I actually prefer it to the 1st place picture)
  9. Yes, and that just proves the Mona Lisa "metaphore" (sic) was argument bait which wasn't taken... Well done.
  10. Yeah, sorry, I edited my post as you were typing that I'd thought you were triggering a DLI to change the "font page" and suffering all the overhead of that. Pete
  11. Or, another application of the VSCROLL trick: Use Antic 4 (multicolour charmode) and copy the same gfx line 24 times. The antic-command "get new gfx line" can be cancelled, so no badlines will show up. Thus, horizontal palette-change kernel (see GED technique) will be possible on ALL scanlines (except the 0th). However, fontpage should be changed every 8 lines. This mode can be regarded as 'extended bitmap mode', as now we could add some zones with 5th colour, without the need of missile underlays. But, there are some restrictions as well. That's cool. So you change the font pointer to change the graphics? Yes. Assume there are 25 char-lines, then 25 fonts are needed. Every char-line containts 40 chars, thus 40*8 = 320 bytes needed. Thus 320 * 25 = 8000 bytes needed for all gfx data. Then organize memory: Split up the 8000 bytes in 25 blocks of 320 bytes, f.e. choose 25 blocks, each starting at a 1kB boundary; f.e. 25 consecutive blocks of 1kB size. The screenmemory then only consists of 40 bytes, and it contains an increasing array of just char-codes 0,1,...,39. Then turning on the 7th bit of one of those 40 bytes will activate 5th colour at that x-position. The restriction thus is: 5th colour select will be from top to bottom. That's a pretty cool idea, but aren't you losing almost as much CPU to the graphics pointer change as the badline takes? *edit* Ok, I see, you're already running a kernel so all that overhead is already happening and just have to squeeze in the lda sta for the gfx bank. Pete
  12. I really don't know how hard was it to convert/draw in c64 format, since I don't really know the machine. From my point of view, both pictures were "only" "conversions" of the original one. That's all. Fair enough if you don't know the C64 limitations but still, one is a drawing of the original, the other a conversion of that.. Big difference as would be seen if emkay attempted to draw (or convert as in import the original movie picture into g2f and work from there) the original to the A8 rather than use someone's skilled intermediate step. I'd much rather see people doing that even if the quality wasn't as good because it means at least THEY have produced something for the A8 rather than relying on someone on a different platform to do the grunt work. Both machines have their strong points for images as we all know. Pete
  13. I simply asked emkay have some respect for artists work, as you'd find in a previous post I explained why and it wasn't that I thought emkay was trying to make out he "drew" it. Pete
  14. No, I don't want to exclude all those pictures, instead I want to include Emkay's one. That's why I have no problem with changing the sig. The author of the C64 picture didn't credited the source either. If you can't see the difference between the work SIT did and the work emkay did then that's your problem If emkay takes the original movie image and converts THAT to the A8, by all means he should put his name on it, however taking the weeks/months of work by someone else and running it through a converter (which everyone would hope would do it ALL automatically) doesn't give you any rights over the image. We're after all talking about two 8 bit machines reproducing a movie image here, crediting the entire movie/effects crew is hardly necessary for an image as well known as Gollum but crediting the guy who did the majority of the work IS. I do however agree somewhat about original credits when people convert something slightly obscure and try to pass it off as their own which happens quite a lot on the C64 from what I've seen. Pete
  15. Just two thoughts to point out: 1. There is no need to change some sig of the artist, if he has drawn the picture on the A8. 2. Leaving the sig in the image is a false regard, because he/she hasn't done the A8 version. Later everyone may think , hey look some C64 artst did some piece for the A8, disregarding the person who converted it. 2. Then don't convert other people's images. Simple. Draw your own else convert them, leave the sig and then credit yourself for the conversion work somehow with a text file, a little text intro before the image is displayed etc. You HAVE NOT done even 1% of the work involved in that Gollum picture being displayed on the A8, SIT did 90% of it, Tebe did 9%
  16. Well, you can tell from the general shape of the image that it's copied, probably "rotoscoped" or traced from the original image (even Tineye will match it to the original picture such as the one linked previously) but it takes a HELL of a lot of skill to put pixels down on a 160x200 screen and have it come out as good as that Gollum picture. If you think it doesn't and just running a conversion app which will create those "pixels" for you and see what mess you get If copies (renderings if you will, and not the computer term rendering) weren't allowed you'd have to destroy 1/2 the artwork in the world or change the attribution to the original artist. That goes for all art, not just computer stuff. Pete
  17. Offtopic: I don't know how original the artwork is: http://midrash.files.wordpress.com/2007/09/gollum.jpg Doesn't need to be original to be drawn by someone on a home computer. It's pretty much impossible to "wire" (scan/convert/whatever method) that image to the C64, SIT actually drew those pixels by hand therefore it's his art. Pete Ok, but that's also true for every G2F images ... errr no, it's very much NOT true. If you load a C64 image into g2f and put a few PMGs on screen, a few DLIs etc, you haven't DRAWN anything, it's in no way your art but your conversion and therefore the "artists" sig should be left alone. Anything drawn by someone in g2f is of course the art of whoever DREW it, not converted someone elses picture, I can do that and I have zero skill as an artist. *edit* Take for example emkay's nilma pic from the top of the last page. If he drew that, put his name on it and I took it and converted it to the C64, I certainly wouldn't have any right to claim I "drew" it. Fine if you want to convert stuff then add a credit file or something to say who did the conversion work (after all, it can be quite an undertaking to do some images with g2f) but leave the artist sig alone. Pete
  18. Offtopic: I don't know how original the artwork is: http://midrash.files.wordpress.com/2007/09/gollum.jpg Doesn't need to be original to be drawn by someone on a home computer. It's pretty much impossible to "wire" (scan/convert/whatever method) that image to the C64, SIT actually drew those pixels by hand therefore it's his art. Pete
  19. i don't think he's posting here any more... (edit: oh, apparently he is! =-) Most of these VIC-II tricks were probably discovered by observing quirks in the hardware scrolling, programmers trying to do one thing and noticing a flicker of something unexpected that can also be investigated; have a look at the C64 version of Last V8 or Red Max for example, it's rare but once in a while the scroll mask will "hiccup" and the status bar will jump down eight pixels for one frame, cultivate that side effect and you end up with FLD. Just to bugger u up I went and posted just as you were typing that Yeah, it was a side effect of a broken FLD routine, I noticed that as well as holding off the line fetch vertically it was shooting it off the the right as well so I messed around with the routine until I realised that 1 CPU cycle resulted in a 1 character/8 pixel movement to the right. After that it was just a case of making it all stable (the original cause of it was that the raster was bouncing around) and then making a routine to do some 2 then a 3 cycle instruction then switch that to a 2 then a 3 so I could increase the cycle count by 1 each time. The funny thing is while I was working out VSP I seem to have found the "put a sprite on your IRQ creates a stable IRQ" thing too Pete
  20. I wasn't going to post on here but I feel I have to. emkay PLEASE stop changing people's sigs on their artwork, you've done nothing to the image as far as "drawing" goes and when google image search finds these and they don't have a recognisable sig on them it's quite possible people will attribute them to someone who just ran them through a converter rather than actually drawing anything. Pete
  21. If anywhere a thread like this should be in one of the Dev sections as José is attempting to port at least the graphical content from C64 games to the Atari. This is 1/2 the problem when clueless people jump into a thread, ruin it by making it off topic or presuming (and blaming José for stirring up trouble, even going as far as claiming he was a throw away account for the trolls to post with) that he's saying the C64 is better than the A8. All STE did was point out that emkay was trolling by posting remarks he knows damn well will annoy anyone OTHER than avid A8 fans. You don't even need to prefer the C64 to see what he was up to. It's like a script, someone posts something trolly, someone else points it out, in come the defenders and blame the person who pointed out the troll, turn it personal or go beyond what is necessary and it turns into another argument. And yes, really no need to bring where people live into it or BP, or would you like to tell us where you're from and we can make assumptions about you based on the atrocities your country is responsible for? Pete
  22. http://noname.c64.org/csdb/release/?id=92257 lol this is even worse... http://www.vuvuzela-time.co.uk/www.atariage.com/forums/forum/12-atari-8-bit-computers/
  23. If you rely solely on hardware collisions you're either going to have horrible gameplay or spend more time designing the game to allow for hardware collisions in the first place and probably limiting yourself in the process. Take Gyruss You can tell a PM colour has hit a PF colour but then how would you tell WHICH of the 20 alien ships on screen you've hit? Take breakout/arkanoid etc. Yes, if you've got an odd shaped bat and a ball shaped ball it's easier to get pixel collision detection but you STILL need to do a software check then to see where on the bat the ball collided because it makes a difference to the return angle of the ball. If you're doing that why not just check the Y pos and then the X, same as checking the hardware registers then the X, means you don't have to worry about making sure the PF/PM combination you're using for the bat and ball aren't used somewhere else on the screen. I'd be very interested to see how many games that use hardware collision and that's proven by turning them off in the emulators actually then call more code to do software checks. Without looking at the code for every game there's no way to know. What happens when you start to "multiplex" PMs? You'll have to run hardware collision routines AS your PMs are drawn.. Hardware collision is useful as a trigger to more refined collisions, in some cases it can be a sole solution but I doubt it's very often. I wonder just how much more complex people think bounding box detection is compared to checking some hardware registers. It isn't a lot, especially if some (no matter how slight) software check is needed as well as the hardware one. Pete
  24. Kratos lol I only really listed stuff I've got working code for (at least "something" running) be it using dummy data or a nearly finished game. The other stuff I didn't want to mention in case I never got time to start them (like tennis). Pete
×
×
  • Create New...