Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

64 Excellent

1 Follower

About laoo

  • Rank
    Chopper Commander
  • Birthday 01/10/1980

Contact / Social Media

Profile Information

  • Gender
  • Location
    Wrocław, Poland

Recent Profile Visitors

5,106 profile views
  1. Hi! Just out of curiosity... did anyone actually beat the game and saw the ending?
  2. A cartridge with fixed 16kB in one block and banked 16kB in other block would be perfect. I'm not sure how much ROM should be enough, because when there are more space available one could employ faster algorithms. The sprite drawing on A8 isn't super fast as I had to squeeze it to 64kB. With more memory some code could be unrolled to maximize drawing speed, so in essence the game could be much faster on such cartridge. There are 5 levels so there are 3 banks per level on 256 kB cart and 6 on 512 kB and I don't know yet whether there could be any gain with doubling the number of banks. Now it's a matter whether enough people could be interested with such cartridge to invest the time and effort to produce the cartridge and to port the game - from programming perspective it's not trivial as the code must be redesigned to use the banks instead of flat memory.
  3. Do I understand you correctly that you are talking about a scheme where there is banked ROM at $8000-$7fff and nothing at $4000-$7fff and to switch the bank one needs to write a bank number to for example $4000? If so I would need a loooot of such banks because there need to be massive duplication of data between banks. What would be cheaper? Smaller ROM with 3-4 logic chips or 1 logic chip with a bigger ROM?
  4. Sorry I don't follow. 5200 has 16 kB of RAM space and 32 kB of cartridge ROM space. You mean that there should be some code in RAM and the whole 32 kB space would be banked? It's doable but somewhat harder to sqeeze essential code to RAM. From the programmer perspective it's much easier to have two independent ROM areas. For example addresses $4000-$7fff could be static and $8000-$bfff banked (or vice versa). Or both banked independently but it's not crucial. I was thinking a little about it and on A8 we did sprite preshifting between levels. It can't be done on cartridge so all data must be already preshifted in ROM, so I think that 8 * 16kB banks could be needed.
  5. Hi! Here's the one of the developers of A8 clone. Our Time Pilot uses almost all available RAM because it has a lot of assets for all the levels. It does not need to be RAM. It can be placed in ROM easily. I roughly estimate that I would need for that a cartridge with about 64 kB of ROM with some banking. I'm not an expert in 5200 cartridge types, so is it possible to produce a cartridge with few 16kB banks?
  6. @solo/ng gave a good point that it's not that obvious: Reaching to cult titles is very risky, because if you'll make shitty port you'll be eaten alive and you'll benefit only if your work will be exceptional. On the other hand you risk nothing with original game. We just took the risk... and didn't win that competition anyway as original game scored better - what may be an anecdotal disproof of your statement
  7. The whole issue is from different understanding what exactly retro-game competition is. I presume that you are perceiving it monolithically and it means always the same, whereas our team has strong demoscene background rooting in the nineties hence our oldschool view on the matter. For us, in contrast to traditional competitions (like those organized by AtariGamer), a competition on the demoparty isn't about making a game as a product, but rather to create a showcase what can be done on specific machine. There's a huge difference. A product is oriented on gaming experience, whilst showcase.... is to show what we are able to do, that others can't. It's about programming skills and game assets are of secondary importance. We've done MK with exactly that attitude: "No one manage to program Mortal Kombat on the Lynx, and look - we did it and it does not look inferior to versions on 16-bit platforms". A fully working game might be a side-effect So in my opinion on demoscene competition such mindset in acceptable and even desired because it's the demoscene. On the other side - as I said before - non-demoscene competitions has different rules to which we comply. We're dealing with recursive concept here. The engine came to life because there were such demanding assets and we wanted to use then. If not that, I would not write it. And frankly I'm pretty sure that there aren't any individual in sight with enough skill that would spend few weeks of his time to draw sprites that would drive that engine. If you know someone, please let mi know and we could make epic fighting game on the Lynx. The engine is pretty reusable
  8. Why just not ask? It's kinda rude talking "they" about people on the forum TL;DR: In our MK port there is not a bit of code from any "Arcade source" and no insight how it was written. The code except Handy Music driver is ~100% ours. I even wrote by myself a custom loader, initialization routines, Suzy handling etc. About making ports in the competitions I'll write at the end, but now I have an urge to write some about the technicalities as it's important to understand the point. So basically the "fighting engine" is only the tip of the iceberg. I don't mean it's trivial, but if you have enough idea/knowledge about game mechanics it can be written in... let's say... a week. Some more if you are doing it in assembly as we did. Actually @solo/ng is a hardcore lover of the genre and he knows all the moves by heart and he was tweaking it until the deadline, so we haven't benefit much from that edition of Silly Venture Under that is a Sprite Drawing Engine intermixed with Resource Management Engine. That's where the magic is happening. I was writing all the tools and 6502 code about half a year - from June of 2019 when I've learned about Lynx 30th anniversary competition and the goal happened to be the Lynx Quest. For that game I did a tool that manages assets and divides the code to separately loaded "stages" and it was designed to make it quickly and easily. It has also pretty efficient routines to draw sprites - virtually any stone and clump of grass is a separate sprite there and you all can judge whether it's sluggish (That's the only reason I was whining in the Odynexus thread as I know that anything that is on the screen it that gorgeously looking game can be drawn faster). When we've decided to make an entry to Silly Venture game compo I was initially planning to do some survival shooter (akin Phobia II) but few weeks before the party @solo/ng presented a proof of concept that MK can really be done and look great on Lynx. Initial concept has been hence dropped and we started to evaluate what is needed to do full fledged Mortal Kombat clone stripped down to Lynx' capabilities. Soon it turned out it would not be a Mortal Kombat that "complies with our standards" if it would sacrifice fluidity of (many many frames of original) animation and if it would not have samples played during fight. So We've faced the same problem that @Nop90 is facing now in his Starblade fighter game. The difference is that the "memory optimization" was off the table because sprites of fighters occupies more that 64 kB. Not to mention many kilobytes of samples... So rather than saying that it's impossible, I've made it possible pushing my resource management way further that's reasonable. At the end our gameplay has about 30 fps what includes drawing two layers of background with parallax, two players with shadows, some UI and few palette changes amids the screen. But the core concept is that we are loading required resources on the fly. The are few pieces of puzzle here: Our rendering takes less than a 1/60 of a second (a frame) so in every 2-frame rendering cycle we have 1 frame for rendering and 1 frame that we are using to load the resources. MK animations have 10 fps, we are rendering 30 fps so any change in sprite occurs every 3rd refresh. Longest animation have 8 frames. We can load 2 frames in one loading cycle so we can load 6 frames before first frame is needed The samples are needed not sooner as at third frame of animation (kick, punch etc) so we have theoretically plenty of time to load all sprites before we switch to streaming sample data on-line from cartridge (in practice there is no much time left as there are two players that need to have animations loaded). Keep in mind that all these resources need to be managed, kept in cartridge, addressed, and have to have some place to be loaded to RAM and accessed without glitches. To speed things up I even devised a way of ordering cartridge blocks so that switching to next block would need shifting only one bit to IODAT. So without false modesty I think that the engine behind Mortal Kombat is really a piece of cutting edge retro-technology that I don't think has been done before on Lynx. And to be fair I wrote it only because we were doing Mortal Kombat that already has resources that are demanding to fit in. If it would be original game I would probably given up and "ordered" simpler assets that would fit in the memory. After saying all this I think that the only thing that is unfair here is to diminish the accomplishment of doing something theoretically impossible only because the idea and assets are not original. Of course there should be rules that needs to be followed. We did original game to 30th anniversary competition because rules said so. We wouldn't submit a port of AAA game on the competition held in this community. On the other hand, @agradeneu, you probably don't fully understand the concept of competitions on demoparties. The idea there is not to present a demo-version of a game that you wish to sell someday later, but to push the limits and present something as impressive as you can. So, please, let's don't mix these concepts. My friend told me that I had very sour face after the announcement of the results But that's the way democracy works. The Silas Adventure had 3D dungeon and we had only two moving sprites. Sadly the majority of voters didn't know what are the capabilities of Lynx and apparently voted using their gut feeling. PS. As a side note about Lynx Quest - I've actually published it's source code about 8 months ago on ChibiAcumas assembly forum and was waiting all that time whether it will be discovered. It wasn't, so it kinda proofs my hunch about very little assembly interest in Lynx community . I stop waiting then and you can find it here. BTW I won the Tiny PacMan with it. PS2. We will push MK further. Multiplayer game waits when I'll stabilize my com-lynx code (as I strongly don't like the way it was done in the redeye). We'll add some more animations too.
  9. I was playing on Lynx with McWill. 20 fps means 3 frame-skips. It might be 3 when there are hardly no enemies on the screen but to my eye it's 4 on average and 5 in hotter places. I've got quite good grabber and should there be a need, I could grab some playout with 60 fps and we could assert it with more certainty.
  10. I was referring to smoothness in terms of frames per second. I presume that the game renders around 12-15 fps which is IMHO just too low for a shooter to play comfortably. I think that 20 fps is bare minimum. This is just a game genere that needs to be dynamic.
  11. Graphically it is an outstanding feat! But if it only could play somewhat smoother... 😔
  12. Generally they have many cool tips on this http://wiki.nesdev.com forum.
  13. And imagine how funny instructions are there given the table is not identity table
  14. Definitely good placement for microSD card slot. When you're developing it's a blessing if you don't need to pull out cartridge to update the image file.
  • Create New...