Jump to content

popmilo

Members
  • Content Count

    1,714
  • Joined

  • Last visited

  • Days Won

    1

popmilo last won the day on October 23 2016

popmilo had the most liked content!

Community Reputation

1,444 Excellent

1 Follower

About popmilo

  • Rank
    Stargunner
  • Birthday 11/01/1973

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Senta, Srbija
  • Interests
    Atari, Commodore, Spectrum, Amstrad and all other retro stuff...
  • Currently Playing
    Hammerwatch

Recent Profile Visitors

20,306 profile views
  1. That cfg file you shared looks similar to ours... Looking at it, I can see where part of the problem was. My own bias towards pure asm born out of 35 years of coding in it 90% of coding I do at workplace is python or plc logic... None of our a8 tools resembles that. For someone like me .byte, bunch of lda, sta, zp etc looks like perfectly clear code... Someone else looks at cc65 cfg file and it makes sense, has words, brackets, everything you would need. But for me that looks alien for some reason Yaron will have what to say about that, he knows more about that kind of stuff than me. I'm the guy who needs to write pure asm self modifying code to squeeze every possible cpu cycle...
  2. Yes we used linker configs, segments, all that jazz... Working with cartridge woul dbe impossible without it. We got to point where We needed all available bytes in middle of ram (bellow antic regs and cart bank window, and above compiled code). We got some glitches, compiler+linker wouldn't complain that segments were overlapping, but code crashed because of some overwrites (altirra helped with detecting that immensely). After a while we realized that even the way cc65 handles calling functions, variables, stack etc is not totally optimal. It could be that if project was only 10% smaller it would fit without problem, guess we hit that redline. I would say probability of arcade game with such complexity fitting in 8bit is greater with asm than in cc65. I can't be a judge and tell you exactly on how many screens, sprites, fps etc it happens but it's there ps. If you know a good way to figure out where things are in cc65 compiled binary I would be glad to hear
  3. I would just add - better memory control. To be honest I was against even trying to do a game like wb in c on 8bit, but Yaron persuaded me that we should at least try A year later I appreciate cc65 much more, it's really gotten better over the years. I would recommend it to anyone coding a smaller utility, turn based, rpg game or similar with smaller memory footprint (or something that can get away with loading stuff from disk etc). Once we got to level size of 1024x50 chars, diagonal scrolling, interleaved charsets and soft sprites, need to know where every byte in memory was got most important. We were getting crashes from overwrites and couldn't figure out exactly how cc65 was allocating memory. In the end switch from cc65 to asm isn't so bad as one might think. In the end it's the same code just written differently Hang in there, it'll come this year Cheers! Vladimir
  4. Message from Jose who isn't currently close to pc where he could send messages himself: @Mario130XE: Wow! that looks really great. Is it G2F or Rasta Converter? Just want to ask is is possible that for skins you 'invert' so that girl has browns while boy has red/pink? This is because of Arcade that we follow on A8 for the sprites. The flower I don't mind, though don't know what others of our Team Hoaxers think, but just asking is if it's possible it'll be using similar violet/pink colours? @Yaron Nir: What about this? If he could invert boy & girl colours? The flower, if these colours are ok for you then they can also be replaced on the Bonus screen. If we use it then I can add Mario onto the Credits screens. We'll talk there later and what others think..." ....... "That's the picture from the Master System version. I knew it from somewhere. Strange or maybe not that boy's skin while in game is pink like on original and all versions (all less the Spectrum ). Seems to be because of axe and flowers contours be brown? You can still keep it. @Mario130XE: Little notes if you can, using first the original (never used Photosop or Gimp but, probably, is simple and automatic): -> 'Paint' the girl skin with same light brown while boy with her pink; -> Move up WONDERBOY logo and the keypress text that between flower and text doesn't have a so large gap. I would propose a gap same high as the one that's between logo and text. This way it'll be more centered on screen;
  5. Sure Catching covid put me behind couple months, and then Yaron got on my neck with wonderboy which we're doing right now, so don't think beatemup or "they are many" will happen before wb engine starts running well. And we should start working on something for Abbuc, so could be one of these old projects in new clothes
  6. You got me on a first mention of Rebol Can't wait to see it running on atari!
  7. Could you share code ? I never understood how "drivers" work on a8
  8. I would recommend Altirra hardware manual. Best book about 8bit Atari imho. Download: Altirra Hardware Reference Manual Wish you many happy hours coding for Atari
  9. Double dragon was the main idea I had routines for drawing those cars, trees etc in "3d" where players and enemies could walk behind and in front. Was missing sfx and collision routines were not 100% done... That was like on morning of the abbuc 2019 deadline So I published what I could, and wanted to work on it next week... Then life happened, I got sucked into other projects and this one was put on hold. I do plan to resume, as soon as conditions become better ps. In the meantime I don't mind other folks trying to make new beatemup, we need those on a8 asap Cheers! Vladimir
  10. There should be I really should finish that game as it deserves.... As soon as I get some extra free time But here is what I found in dev folder: warriors.xex
  11. Really @José Pereira why wide pixels ? You know I love them, but don't understand the need
  12. You're right with that. And it wouldn't look bad at all. Here is uridium gfx scaled twice vertically: It should be redrawn for smaller vertical space, but honestly I would rather fly over such a big ship with screen scrolling vertically too. Reduce gfx details to fit in 128 chars. Use two player pairs for two enemies in a scanline, make bunch of them in mostly vertically spread formations. Making player ship with soft sprite is then easy and can be very optimized. Now that would be a proper a8 shooter.
  13. Tried that with sound playing once, in the end that "every other line" took so much precious cycles I abandoned the idea. Guess it depends on a game complexity, in some cases it would work. For me Uridium is just an example of 50fps shooter. I have no fixed goal in mind regarding it's gfx or gameplay. Finding the best way to show that same speed and look on a8 is the challenge.
  14. Why is your math like that ? Shouldn't restoring background be faster than drawing masked sprite ? "24 pixels width" - you mean hires pixels ? So 3 bytes like c64 sprites ? Imho drawing is like: 21 line x 4 bytes (4th is for shift) x (lda+and+ora+sta = 5+5+5+6 = 21) = 1764 Restore would be simple lda+sta: 21x4x(5+6)=924 So even worse than your calc... That would be tight indeed... 3 buffers is something I never tried on 8bit, probably because of memory needed Although it would be only around 20kb in atari case... And most of the time all sprites move so wouldn't make much difference maybe. At least calculation like this shows that chances of something like this working on A8 is much higher with double scanline mode Somebody will code it, and we'll see what can be done
  15. Forgot to add those files Joystick moves cursor Fire - enter build or move mode. (fire leaves build mode, marked by blinking cursor). Archers can be moved directly after selection. Press fire again to release control of the archer. Archers will shoot at enemies automatically, just leave them in some area where zombies are coming from. When you press fire on empty terrain, cursor will blink. Move cursor left, right, up, down and press fire again to build stuff (cursor shape will change so you can see what will be built). Build lamps to produce power and expand vision. Build houses to produce food, wood, rocks and workers. Build archers to expand your colony. Most important - build houses near wood and stone becaues game counts how many of those tiles is around the house and gives you that amount of stuff per turn. Sorry if it gets buggy sometimes, something with that adding resources part is f-ed up... At the start just build one house near forest, expand right-up with archers till you get to stone. Then build house there and wait till you get resources. You can build walls, more archers etc... Enjoy in the promise what could've been As soon as I get better, I'll fix bugs and make new release. Cheers! Vladimir they_are_many.xex
×
×
  • Create New...