Nop90

Yes, I have the old clock.s file, but I downloaded the last version of cc65 from your site. Maybe in my setup there is some garbage from a previouse setup not properly cleaned. Thank you for finding the problem. I'll let you know if a fresh install will solve the issue.

No luck. The new template builds, but like the other one it freezes on startup. The toolchain was downloaded from your repository and built like you say. If I can't find a workaround in the next days, I'll clean the toolchain and build it again. If nothing changes, I'll move it to a windows machine.

The header is there (or it won't compile) and tryed to add more space to the RAM segment (used the cart template and changed RAM from $3000 to $3800) with no luck. But I think the problem is something else because I compiled the template code with no changes and there is the same problem, so looking in the code I found the clock() function in the intro. Commenting out the whole intro code, the demo works fine. I think there is a problem with my compiler: I had to compile the CC65 from the code on your repository because my Ubuntu machine (64 bit) doesn't run the pre built tools.

I created the cart structure using the cart template and almost everything went fine, but the game freezes at startup if I use in the code the clock() function or the CLOCKS_PER_SEC value; The same code works loading the whole code in ram (without using the cart structure), but while in a cart structure the code freezes even if the call to clock() is in a part of code not loaded (at startup I load the intro, but the call to clock() is in the game section loaded from the cart after the intro). Could be a problem of the linker? Does somebody else had this problem? Can you find me to find a solution?

Thanks. I know the basic concepts of single and double buffering, have only to make some experience with them on the Lynx. Finished adding the levels to the cart structure, now I'm going to implement the data structure for the level map and the loading code, than the new drawing logic.

I'm restarting the port from scratch. Drawing tiles is one of the reasons for low FPS, but the other one seems to be the use of an array of struct for the gamemap. I'll code something faster to address. At the moment I created a new cart structure with the intro, the main code (for now only the menu,the pause screen and the gameover screen), the different backgrounds in separate cart files, and the first bg music (also in a cart file). Now I'm adding the 48 levels data in separated cart files. I think I'll load them in the back buffer because I need them only to setup the level map at the beginnig of every level. This way I can save another 1kB of memory. If I don't use animated tiles I can draw the full level only once, than I can draw less than 20 chained sprites every frame. This should give a good result. But to do this I have to understand how to use a single buffer. Using two buffers I need to maintain the two buffers aligned (every frame I have to draw the previous changes than draw the new changes) and this doubles the number of sprites to draw. Can you give me an hint about this? If I can use on lynx a smart trick, a code snippet would be apreciated.

Chained sprite. This is new to me, but now I understand that *next in the sprite struct. So I can declare an array of sprites and initialize them with the game map (position, pixels data pointers and the chain) when loading the map. Thanks, I'll try this way.

In the site structure I'm only changing the pointer do the pixel data, the I let Suzy draw it. I suppose this is faster than writing directy to the video buffer. I set the screen refresh at 75FPS, 50FPS is what i get o the emulator doing almost nothing.

I'm using 3 sprites. One for the game header (where score and time are placed), one for text chars and one for the tiles (about 20 tiles). Here is a screenshot of the game screen: Please don't judge the gfx quality, they are only a fast rescaling of the original tiles. If this project reach an acceptable level of quality we will hire a gfx artist to make better graphics. At the moment I'm testing the code to find FPS bottlenecks. Commenting out the tiles drawing loop and the animation logic (i.e. drawing only the header, the topscreen numbers and the player tile) I have 50 FPS. I can't go faster than this even if I remove all the drawings. Maybe an emulator limit? Simply using tgi_clear() the framerate drops to 25 FPS. I'm avoiding to use it. Both the tiles drawing loop and the game logic are very CPU intensive, so I', going to work them now. I also tryed using a single buffer, drawing only changes to the screen, but the speed is still to low and I have a lot of flickering, so at the moment this isn't a good solution.

Assembly is an option, but my ASM skills are very rusty and I should rewrite all the game engine. Probably I'll try to optimize a little more the C code first. The screen is very static, there is only the player sprite moving and some animates tiles. The alpha version I have is not bad IMHO, getting some more speed could be enough. At the moment I'm testing it with mednafen on a Linux VM on my PC, and with the online emulator on atarigamer. I'm in the waiting list for a SD cart, so I can test it on my Lynx, but I don't expect big differences.

I'm working on the port of Xump for the lynx and at the moment I have a working alpha with one level and without music/sfx. The first working build had about 4 FPS during gameplay. Optimizing the code I reached steady 7 FPS. Now I'm moving things in a cart filesystem to load title screen and menu backgrounds only when needed, so I can have other memory to make more optimizazions. I think I can reach about 10 FPS, but no more, mostly because to maintain the original level fomat I have to use small 8x7 px tiles. Kojote, the Retroguru team leader, thinks this is a too low FPS for an official release, but it seems to me that some commercial games have worst FPS. What do you think about this? Is it worth to continue the project with such a performance limit?

Please add me to the list for one cased LynxSD cartridge. Thanks!

Thanks, this makes sense. So after all it's a coding convention. This brings to my mind that I made an error with some code I wrote to relocate roms to phisical 13 bits addresses (trying to save some instructions to make z26 run at acceptable speed on the 3ds); I relocated 2k roms to 0x1000, just like 4k roms, but the correct position should be 0x1800 to have the interrupt vector(s) at the right position. Strange thing is that the relocated roms work fine on the emulator (using javatari), but probably it's because the emulator, with 2k roms, ignores bit 13 of the addresses (just like happens with phisical 2k cartridges)

Just for curiosity (probably this is a silly question). Why is so common in 4kB commercial roms to have start address at 0xF000? (same for 2kB roms starting at 0xF800). My idea is that this could be related to the original atari dev kit. Maybe to run the code in debug mode on the host developement machine in a memory area normally unused. Or maybe it's only a coding convention.

Play button never works for me, but I use the keyboard to play the instruments at different notes. W key should be a nice D4 (or D5 can't remember now) on the +0 octave.

Thanks, I'm working on other 2 projects for th Lynx, but after this simple game I know there are a lot of things to study deeper to code nice games. I'll post a preview as soon s I have something playable.

Added v0.2 to the OP. Decided to not add a music for the game, only for the title screen. Instrument used fo music and SFX aren't so great, but without a real lynx for testing sound dosn't make senso spendin more time with them. There is still a problem with the music, that plays bad returning to main screen after a game. It's related to using SFX. Have to study better the sound handling.

Managed to fix palette output in sprpck. The code assumes the use of windows bmp v1, that has a fixed header size, but since the time sprpck was originally coded micosoft evolved the bmp format adding other bmp versions with variable header size and optional data after the header. To fix the code I read the some data from the header itself to locate the starting point of the palette. Didn't tested it with every possible bmp format, but at least with the files generated from GIMP it now works fine. If someone is interested in using sprpck instead of SP65 i can upload the fixed code on my github.

Hallo everybody, this is my first post. About a week ago I decided to learn Lynx coding, and after setting up the toolchain on an ubuntu virtual machine I made a lot of experiments. My goal is to port one of the Retroguru games, and I'm at good point in making their platform engine to work, but I'll need some time to master the build of a lynx cart for a project of big dmensions. So to make experience with the new toolchain I decided to make quick port of a smaller game and opted for Biniax v1.2. Attached there is the alpha version of the game. To finsh the game I need to tune the font that I made for the game, add some fancier background and add musics & sfx (alredy have a working tune made with Chipper, but the instruments need fixing, they sound so bad in the emulator respect at design time with chipper), but the game is already fully playable. Usually I try to solve problems on my own (luckily there are a lot of informations on this forum) but if I find a big problems I'll ask your help. When the game will be finished I'll release the sources too. Meanwhile every feedback on this small project is welcome. Nop90 Update: final release here http://atariage.com/forums/topic/288541-biniax12-port-for-lynx/ Preview version (v0.1) Release version (v0.2) biniax1.2 - Lynx Port v0.1.zip biniax1.2 - Lynx Port v0.2.zip biniax1.2 - Lynx Port v0.3.zip biniax1.2 - Lynx Port v0.3 - src.zip