Jump to content

Muddyfunster

Members
  • Content Count

    403
  • Joined

  • Last visited

Community Reputation

432 Excellent

1 Follower

About Muddyfunster

  • Rank
    Moonsweeper

Contact / Social Media

Profile Information

  • Gender
    Male

Recent Profile Visitors

3,158 profile views
  1. Bloody hell Karl That would be some undertaking!
  2. I have a 7800 now and I'd love some sort of SD system so that I can test code on a real machine. Guess I'll have to keep my eyes open.
  3. I'm tempted to try an even taller version of the swordsman with proportions like those in the Barbarian games, rather than platformer or RPG sized.
  4. Thanks for the feedback, appreciated. I worked a bit more on this and added some frames for the swordsman doing a chop. Here's how he looks. I'm not 100% happy with him yet but the whole point of this for me is experimenting with a new medium, so with that in mind, it's so far so good A7800_ Atari 7800 (NTSC) Cool [a7800] 2020-02-20 16-03-16.mp4
  5. Thanks @Trebor & @RevEng I tried making my sprites thinner and maintain the height so they didn't look so chunky, that worked really well and I think for certain sprites that would be best, I guess it's situational. I also tried increasing the height per @RevEng's suggestion and that also worked really well but I've always liked big tall sprites. My first try looked ok in the sprite editor (left sprite) but jebus, you would have needed a team of sherpas to cross the guy's chest when he rendered in 160. I made him taller and slimmed him down just a touch and those proportions worked out nice when rendered. The barbarian is a bit meaty still across the chest but I think he wears it well. Finally getting the hang of indexes and palettes!
  6. Thanks Karl & SlidellMan, The Warrior graphic was just an experiment, probably not going to get used in any game for now. I'm mostly figuring out what does and doesn't work on the 7800. With the 2600, even with DCP+ I found I had to rely a lot on "negative space" to create detail in the sprite and suddenly having 24 colours on screen to play with provides a lot more flexibility that I'm used to lol. Even with the dabbling I do on other platforms like the ZX Spectrum, I don't have this amount of colour flexibility out of the box. I do find even 16x16 sprites look quite chunky in 160 so I'm going to experiment more with them and also some 8x8 sprites. I have about 20 ideas for games that I either ran out of motivation for or the idea wouldn't have worked well enough on the 2600 that I'd like to revisit at some point, like a village management game for based on the old BBC Micro game Yellow River Kingdom, so lots of ideas to get on with. I still think converting something like Dare Devil would be a good start so I can learn as I go.
  7. Think I've figured it out, lots of trial and error and shifting the transparent indexes out of the way.
  8. Sorry, I'm back with more questions I managed to get banners and 160A sprites working quite nicely however I've found working with 160B sprites and managing the palette to be very challenging in an environment where I need to have multiple sprites sharing a palette. Apologies for the long winded explanation : Using the sprite editor, I created 2 simple test sprites (attached below), both using the same 12+1 160B palette. Warrior (original sprite - red cloak) and Warrior 2 (a copy of Warrior but with a couple of colours changed - blue instead of red). In the picture below, row 1 is Warrior, Row 2 is Warrior2, Row 3 is Warrior and so on, attached program demonstrates a screenful of red cloaked warriors (program file attached - "Warrior no index"). In this sample I set my palette up, adjusting until Warrior 1 had everything the right colour. I then added the second PNG to my program and displayed them with the same palette, I expected "Warrior 2" to be off as I set it to use 2 colours different to the first PNG but they both display identically, so the interpreter is treating the reds and blues as the same colour (indexing I assume?). In the sprite editor they are different colours in different slots but I assume when they are encoded to PNG they are just "colours" the red and blue sharing the same spot in different files. ah ha! I'll swap the offending colours around using the index thingy when I load them in. In the second picture I've set the colour indexes to what I assume should be the default for "Warrior2" so that I have a starting point to figure out what colours to swap to ensure red swaps to blue. Like so : incgraphic gfx/warrior2.png 160B 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 I was expecting the same initial result as in picture 1. Nope, it sets them to something different including moving some of the transparent colours to actual colours so 0 1 2 3 4 5 etc is not the default. So I have to set both PNGs to 0 1 2 3 4 etc and then start from scratch moving colours and transparencies around, and then fix the palette I'm hoping i'm being really dumb and I'm missing a trick with this. Being able to share a palette for different sprites is key to the ideas I want to develop using 160B My understanding of the syntax of incgraphic is that the numbers specify the colour palette "slot", so if I think for example that the colour red in slot 3 and blue in 9 are in each others place in my sprite, I can just flip them so I end up with something like incgraphic gfx test.png 160B 0 1 2 9 4 5 6 7 8 3 10 11 12 13 etc? I assume that 0 = first transparency in palette 0, colour 1 = P0C1, colour 2 = P0C2 and so on. Am I missing some secret 160B sauce or is it a process of elimination until you get it right and setting the index to a default like 0 1 2 3 4 5 etc. If so, that sounds awfully long winded to set up graphics in a game where there are a lot of sprites sharing a palette. I also tried with Gimp making a 13 colour indexed png with pretty much the same result. Any help or guidance would be really appreciated and I appreciate there are some crossovers with the other thread I made on 160B banners. warrior no index.bas warrior indexed colours.bas
  9. This! - thanks Mat! Plus some of my insanity was self inflicted, I was calling palette 5 twice and no palette 6 so no matter how hard I tried, I couldn't understand why P6 would not change. I came back an hour later and boom, there is the error. Grr...! Steaming on now though. I've got banners displaying and sprites moving. All experimental for now but I am thinking of something like converting DareDevil to 7800 Basic as a learning project. Despite my early (mostly self inflicted frustrations) 7800Basic is a lot of fun! (thanks @RevEng!)
  10. Thanks SmittyB, it's the import parameters that I'm struggling with. I'm mostly using Gimp 2.1 I kinda get the concept of the colour index but when I alter it to try and match to my original idea in the editor, I don't seem to make much headway. Changing the sequence should put a different colour in a different slot by my understanding (sorry for murdering the syntax!), but lining them up as intended, that's where I think I'm falling down. sometimes it works and sometimes it doesn't despite hours of trial and error. On 3+1 regular palettes it's fairly straight forward and I can manage that ok. On a 12+1 its a bit of an issue for me I think due to the number of permutations. There's probably something i'm overlooking or something I've missed that makes this a lot easier or an easier workflow. [edit] noting that i'm talking about sprites as the "anysize" banners in 0.7 is great
  11. Thanks Anthony, I think I might have figured out a way bu dropping the new 7800Basic distro in the compilers folder overwriting the existing 7800Basic. So far it seems ok, and my program complies with 0.7 instead of the older 0.6
  12. the 160B palette is such a nightmare to manage on sprites. I get one colour in the right slot and the other half of the sprite thinks it's time to be transparent lol. Frustrating isn't the word!.
  13. @mksmith is there a way to update the studio to the latest version of 7800Basic? I had a look but I couldn't see a config setting.
  14. Thanks, I think i've got it now I'm sizing banners correctly and respecting the zone height boundary and I'm making progress with the colour indexing. My next thought is on palettes... if I run with 160B for my title screen, can I revert to 160A later for objects and can I redefine the the 160B palette (ie palette 0 to 3) later to have "game colours" instead of "titlepage" colours, so in effect, I have a title palette and a game palette? Sorry if this is covered already, I've searched and found some interesting threads but I didn't see anything definitive. I'm trying to see how much palette flexibility I have and whether to structure my palettes, sprites and graphics in 3+1 or 12+1 sets. I won't have tons of sprites so the overhead of 160B for extra colours (in a sprite) is a good trade off for me if I understand things correctly.
  15. ah sorry I missed that, thanks @RevEng . Every day is a school day for me with 7800Basic right now
×
×
  • Create New...