Jump to content

johncl

Members
  • Content Count

    23
  • Joined

  • Last visited

Community Reputation

3 Neutral

About johncl

  • Rank
    Space Invader

Recent Profile Visitors

3,730 profile views
  1. Just wanted to tell that everything arrived, was well packed and in great condition. Thanks!
  2. Expressing an interest in the following Commodore 64 games (if they are C64 that is): - Zorro - Purple Turtles - Bugaboo - Falcon Patrol - Hideous Bill - Castle Wolfenstein - Bandits - Blade of Blackpoole, The - Capture the Flag - Serpentine (if cartridge) - Potty Pigeon - Professor I.Q. Also if this is Vic20: - A.E. Will PM same list with offer per title.
  3. Any news when the next batch is shipped?
  4. There seems to be many more carts in that photo compared to the list of buyers on the top! Do you have a complete DDI Telengard still for sale?
  5. It wasn't until way later with machines like the Amiga you could do colour cycling by swapping palette indexes around, and ofc later with PC 256 colour palette VGA graphics. I guess some sort of colour cycling is possible on a machine like the C64, but only 3 of the colours in a multicolour sprite/character set (you have to update the character colour by writing in colour memory in order to change that). The usual way to fix it is to use rasters and just update one of the colours (not the character one though) so in that sense its basically the way the Atari 2600 would do it too. Ofc with the Amiga you had dedicated hardware that read a raster configuration (called the copper list) making these things exceptionally simple - hence all the "raster bars" (or "copper bars" as they were called) in Amiga demos. - Its one of those little things that made coding games and all that so much simpler on the Amiga.
  6. Read the Pacman Dossier web page, it really details how the arcade was coded. There is no "bounding box", Pacman and the ghosts are in one tile at a time and they move at an offset from this tile. The "bounding box" is the tile and that is used for the collision test. Furthermore pacman can corner turns meaning he moves diagonally for either 3 or 4 pixels depending on which direction he corners from, hence the ability to reach a tile faster than if he had to move all the way into a full char position before turning. Cornering is essential for any seasoned pacman player to gain a distance from the ghosts and indeed to follow any of the known patterns for maximum score. The definitive proof of this tile positioning is that pacman can in fact move straight through a ghost as the collision test is done after both pacman and the ghosts have moved, and thus enables pacman and a ghosts tile position to just miss each other at the right spot. Check out some youtube videoes of this demonstrated - although its very vell detailed in the Pacman Dossier.
  7. It's rather common within any games programming even today to use placeholder graphics, as you can almost complete most of the major game logic before thinking about graphics. Ofc the big game projects have already tons of resources allocated to graphics and a lot of it isnt ready before very late in the development cycle so programmers have do work with placeholders for a very long time, even simple 3d primitives in complex 3d games.
  8. Most games have inherit "features" based on the order of the logic. Pacman also has the well known "feature" where you can run straight through a ghost simply because collision detection is done tile based and both pacmans and the ghosts move logic is executed before the check for a collision between pacman and the ghosts. If you want to go realism I guess Pinky and Inky should both suffer from the up vector offset bug (2 up and 2 to the left and 4 up and 4 to the left), I am sure all seasoned pacman players know about that one and use it to their fullest.
  9. Very nice project. Having dabbled some with a pacman clone myself, the Pac-Man Dossier is a well studied page. Just wondering, have you coded the angular "cornering" logic for Pacman? I always found this piece of information pretty fantastic for a game developed so early. Like being able to affect where the barrels roll down in Donkey Kong, these tidbits of code makes these games stand out from the crowd. No doubt these were also features that likely all the clones missed.
  10. Starting with how it should look when its boxed sounds like "jumping the gun" a bit. I'd say you first need to figure out what kind of game you want to do or start experimenting with some challenge. 8bit systems have some very nice challenges due to the limitation of the hardware, which also means one might even get away with sub-par graphics skills too if the game is good. The more advanced the display hardware is, the harder it is to make it look decent. A system like the Atari 2600 is extremely challenging though compared to most other later 8 bit systems. Memory constraints add to this challenge, and there are systems in the middle like an 8kb Commodore PET or a 3.5 kb Vic20 that can be good platforms too. Personally I am a Commodore 64 guy and can relate to the post by Christopher above, its littered with unfinished projects. Most of them end when the coders challenge is met in e.g. some cool display technique. To finish a whole project takes perseverance and motivation of a different kind as there surely is no money to be made on this either. So far I have only completed one C64 project, a Jetpac clone called Rocket Smash where I did a 16kb cartridge version with Saul Cross (who did graphics and music) for the last RGCD cartridge compo (we got 5th place). A fuller 64kb version with a story and digitized samples is practically finished (just need to fix some text in it now) but it took ages for me to motivate myself to really finish this in spite of a deal with RGCD to publish this on cartridge too. I have another project with Saul Cross as well that is about half finished, but again its a lot of work now left and not many big challenges left so it takes some special motivation and indeed time to commit to the last half bit of hard work. Although I know the game will probably be well liked by the community when its eventually finished - I still have a few other secret pet projects that have potential but are also daunting amount of work to get to any finished state, haha. So do not think too hard on the finished project - but enjoy the way there.
  11. Just wanted to congratulate on a fantastic job. I am not an Atari guy really, but somehow got fascinated by the programming of this console as its a fantastic challenge. Having played some with programming for the device its certainly amazing what you have managed to push through the Stella. But I understand you also rely on some external hardware? How does that work, will making cartridges with the game be very costly?
  12. Hi, I am a Commodore collector and creator/coder of the site http://retrocollector.org where we add scans and photos as well as preserving tapes. I am seeking to complete my tapes collection which no doubt will be a seriously long mission. But the main wishlist of tapes is growing shorter by the year and if you have any C64 tapes for sale/trade then please do check my wishlist here: http://retro.lonningdal.net/wish.html My main focus has been tapes, but I also collect disks and cartridges. I don't have many US tapes on my wishlist yet but I know I miss a lot of e.g. Victory Software titles. Here are some examples of titles I am seeking:
  13. Old thread, but I just wanted to point out that indeed the C64 has a multicolor character mode where each pixel is paired with the next one effectively making chars 4x8 resolution but at double width. Which is why you see those wide pixels on many C64 games. The same thing goes for sprites. And essentially its was not a bad thing on a bad PAL/NTSC composite signal where you wouldnt be able to see the pixels that well defined anyway in the horizontal resolution. Furthermore as people have pointed out the special sprite to background priority was one of the nice features of the C64 but it had a fun little "quirk" in that both bit pairs 00 (background) and 01 (multicolor 1) was considered background, so that the sprite would be in front of these in all cases even when you set the sprite to be behind "chars". While some would "palmface" at this design constraint, games like Fist II used this to its fullest enabling the sprite to move in a charset environment with a somewhat detailed 2-colour foreground and 2-colour background imagery. However a disadvantage was that multicolour char mode had a nasty limitation, you could only use the lower 0-7 colours as character color (bit pairs 11) as the colour set for that particular character defined whether the char was in multicolor mode or standard highres. So your normally 16 char colour option was reduced to the first 8 as the 4th bit in the char colour memory decides if its multicolor or not. Its a bit tricky to understand from writing, but essentially when you set the char colour to e.g. light blue, the actual char colour would be standard blue for the bit pairs 11 in the char data. For multicolor 1 and 2 as well as the background you could select any of the 16 colours. To make matters even worse, many of the good colours were in the upper indexes 8-15: brown, light red (pink/skin colour), dark brown, 3 greys, light blue and light green. That meant if you wanted to e.g. use all 3 greys in your multicolor charset you would have to set background to dark gray, mc1 to grey and mc2 to light grey. You were then limited to the lower 8 index bog standard colours for the char colour (black,white,red,cyan,purple,green,blue,yellow). Many like to bash the muted pallette of the C64, but in my opinion one of the strengths of the C64 pallette is the many greys and "earthly colours" which makes it ideal for many games featuring some kind of nature. The nice skin colours help a bit too naturally. Save the bright colours are for spectrums and Las Vegas. Anyway, you can imagine the interesting challenges a C64 graphics artist is often facing when selecting colours! Lets say your game needs some trees, ah wonderful, we have two browns and two greens. Splendid! Hey wait a minute, hmmm... both browns and light greens are in the upper indexes... Dang. Ok so we need to reserve both MC1 and MC2 as well as BG for these three colours and we can use the standard green as char colour. Voila a pretty tree! Hmm, but the whole background of the game is now either light green, brown or dark brown. Oh oh I want a green grassy floor with dirt underneath, no problemo, colours are all ready to be used. Oh and I want a blue sky using both blues!... Hmmm... one blue is char colour, but the light blue is upper index colour! And my green tree cant use green char colour on the chars that are also partly sky. Dang! This is where the artist and coder has to come up with trickery to enable more colours "in the mix", and it is possible to change both MC1, MC2 as well as BG for every scanline if you so wish with some raster code. In our example, we could use the light green on the edges of the foliage of the tree with holes in them to let the blue shine through (as we have changed our char colour for those tiles from green to blue). Additionally we could change the light green MC colour to a light blue when the trunk begins to use the light blue for a sky gradient at the horizon, and then swap it back to light green when the ground begins. Now if you want rolling hills in your background scenery you would have to use char colour green on those tiles and save the light green details for when the sky is finished. Many tricks are possible with some smart use of char colour and changing them on the fly during the drawing. For C64 enthusiasts, pause the games you play and try to figure out what colours are used where for BG, MC1 and MC2 as well as char colour. Sometimes you will be surprised at what they chose. Some games have a black background, and you might immediately think, they have set the background to black, but what they often do is use char colour black and the real background colour shines through the "holes" drawn in the chars whenever needed. In most cases this is because the game required the use of 3 upper index colours. In many cases you have to make sacrifices and e.g drop one colour so that you have more freedom with the char colour to add detail. In some cases you resort to sprites for some missing details although that will again limit your use of sprites on top of the scene since there are maximum 8 on any one horizontal scanline (you can multiplex and reuse sprites on different scanline locations with some limitations). Additionally, the sprites also has a nasty limit, their multicolour indexes are shared between all sprites (much like chars but the registers are different so you can have other colours for sprites multicolours). But you are at least free to use all 16 colors as the sprite colour. Again, you can change sprite colours at any raster to get more colours here as well if the sprites are spread vertically (for SMC1 and SMC2 colours at least). Atari 2600 programmers know all about changing colours for every raster so it shouldn't be a surprise this trick is often used on the C64 too. The multicolour char and sprite modes are important features of why the C64 became so popular as it enabled a rich visual style at a time where home computers often had single colour chars and a small pallette (the Atari 2600 being an exception on the palette selection naturally, although very limiting in every other aspect of graphics). But it comes with a price as you have seen, and for the C64 graphics coder it often becomes a challenge to find the best tricks to enable as much use of the 16 colour palette as possible, much like an Atari 2600 coders challenge to squeeze as much out of every rasterline the code sets up. Both equally fun for a seasoned programmer.
  14. Just a quick question. I felt like reinventing the wheel and doing a 6 digit score. I assumed it was done by using the two sprites next to each other, set them to repeat 3 times and then change the GRP0 and GRP1 as it draws over the screen. And I guess the idea is to use the stack register as extra storage since that only uses 2 cycles to transfer the value which is just enough to sqeeze in that last sta GRP1 to set the 6th number. But is this safe? And it works fine for me now in Stella, can I assume its working on real hardware as well? Or are there things you can do in Stella that allows TIA trickery beyond what the real hardware can do? Also one last question. Is it possible to reuse the sprites on the same raster line in any way all? (Even if I cant move it but always relative to previous location?)
  15. Btw I tried out Stay Frosty, and its a brilliant platformer with some nice challenges as you get into the game. The only thing missing from it is a level number indicator and perhaps a bonus life there now and then (perhaps there is). I love the detail and expression you have gotten into that snowman, I guess you have used the missile and ball a lot on him. I was hoping to give my hero some eyes using the ball and perhaps some other tiny details. But I dont think I have enough cycles to do that. The screen I have now looks fairly nice but with a mirrored playfield. My next challenge is to update it during draw so its asymmetrical and I need to draw one sprite as well in the same scanline but I guess I will try to use some assumptions that the next data is available always so I just pad the end of the sprite with zeros to avoid any sort of checks. At least I have seen that I need to make my kernel quite a bit larger and split the drawing up into sections since there will be whole lines where there is no playfield (but only background color and the main player sprite). These are perfect places to multiplex the other sprite. I guess I should design the game for NTSC and 192 visible lines and just have more border on the PAL versions (or extra decorations).
×
×
  • Create New...