-
Posts
173 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by jum
-
-
Fun game! Great gfx, sound and gameplay.
Never played it on Atari 8-bit before. I think it's the sort of game that fits the Lynx perfectly.
Played on Lynx II via RetroHQ SD cart.
-
Well I did finally manage to get the game running on my Lynx II with RetroHQ SD card. I blame TGI for messing up my fancy "dual layer SCB" system
Game is very fast on the real Lynx (and a bit blurry!), but very slow in Handy...
Here is the latest version:
- 1
-
Hi Karri, actually I just now found the cause of the crashes (after a LOT of SD card swapping :{ ?
If I disable collisions, the game does not crash. I'm using the default TGI config with 2 draw buffers and collision buffer like so:
// tgi locations of collision buffer (using -C lynx-coll.cfg in linker)#define COLLBUF 0xA058#define BUFFER1 0xC038#define BUFFER2 0xE018So possibly the stack is getting overwritten (underwritten?)? IDK, maybe something else?
-
Still need to get it running properly on a real Lynx...
-
Yeah, judging from the screenshots, the quality of the entries looks very impressive, way better than previous homebrew compos I've entered!
- 1
-
13 hours ago, necrocia said:
To all of the competitors - you should have an email from Atari Gamer, please have a look and respond accordingly. Let me know if it ended up in your Spam folder too.
Emailed a pre-release version of my compo game back to sender.
-
My game "Sky Raider" is almost finished, but as usual the last 10% takes more time than the first 90%
I also need to compose a very short tune for the title / start. Something "stirring" similar to Apocalyse Now / Voyage of the Valkyries, or Star Wars, but shorter and simpler.
Also still need to test/fix on real hardware, and do some optimisation/tweaking/polishing...
Don't know if I will get it to 100% done before submitting. But I know if I submit it now, I will stop working on it...
Here's the title screen sprite:
- 3
-
The "Apple IIc Reference Manual Vol 2" has a section on the differences between a 6502 and a 65C02 (see "Appendix A"), that I came across today.
A few instructions take 1 less cycle, and one instruction (JMP abs) takes 1 more cycle.
The BIT instr affects status register bits differently, and JMP indirect can differ.
-
20 hours ago, Nop90 said:
It's faster if I post it here.
Thanks - much appreciated
-
On 11/4/2018 at 2:54 AM, Nop90 said:
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.
Thank you Nop90. I have also had this "bad palette" problem with sprpck and BMP files (generated using GIMP).
Please add a link to your github with fixed sprpck. Thanks.
-
On 6/20/2019 at 12:34 PM, Nop90 said:
The drawback of your struct is that it expects to chain always sprites of the same type (in this case a full sprite with scale info, palette and collision data) while having a field with a pointer to a generic char array allow you to chain different sprites types, that in the end can make you save memory.
Hope to not seem rude, I don't want criticize you code. Often I wrote ugly code if it works at first try. I'm only giving my 2 cents to encourage the discussion.
No offense taken It's just an alternative way to set up simple SCB chain. You could also save 8 bytes per sprite by leaving the palette mapping out of your SCB struct, and manually setting the palette mapping before drawing the sprite chain. Depends on what you are doing, how many sprites you have, etc.
-
This is how I have my SCB struct defined:
// Lynx Sprite Control Block structure typedef struct SCB { uchar sprctl0; uchar sprctl1; uchar sprcoll; // spr collision number struct SCB *next; uchar *data; signed int hpos; signed int vpos; uint hscale; uint vscale; uchar palmap[8]; uint collResult; // collision result data (offset = 23) } TSCB;
Note "struct SCB *next;". This allows us to reference the next SCB without casting, like so:
struct SCB clearSCB = { 0xc0, // 4bpp / bg_no_collision 0x10, // compressed, hsize/vsize 0x00, // 0 to clear coll buffer &playerSCB, sprclr, 0x100, 0x100, 0xa000, 0x6600, { 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef }, 0 };
-
Yes, I've read the full tutorial on how to set up and compile the dev environment (thanks for writing them).
To be honest, as it looked like quite complicated with a lot of stuff to install, I was hoping that there was some precompiled windows builds floating around, even if they are not up to date, so I could go through a simplified / easier process .
Do you confirm me that they're isn't any compiled release available?
I am using a precompiled Windows version of CC65 (on Windows 7).
Just looked up where I got it from: https://sourceforge.net/projects/cc65/
It seems to be 4 years old now.
I followed the link from the CC65 main page: https://cc65.github.io/
Not sure if there is something better now, but this version is much better than the "old" cc65.
Edit: Looking at the https://github.com/cc65/cc65 src files, it seems there is some recent activity. May be possible to build cc65 using Visual Studio?
- Jum
PS: I anyone has any ideas on how to do a fast vertically scrolling playfield on the Lynx, please let me know. At the moment I am experimenting with using 2 80 x 102 sprites, stretched 4x horizontally.
-
-
I'm a gonna register (as soon as I decide what I want to do).
Haven't entered a console programming contest since 2005! (Chopper X in PDRoms 3.33 competition).
May pull out an old unfinished demo/proto and finish it off, or maybe do a very simple new game, probably involving dachshunds...
Alternatively, I can be a judge if you need one.
- 1
-
Bug report on real hardware:
- The ghosting of the walls is pretty bad.
- Sometimes when there is a robot above me I try
to shoot up, but nothing happens. Even if I move
up a little, it still does not work.
Thanks Chris. Not sure what causes the "ghosting" of the vertical walls, I just assumed it was my Lynx' old and crappy screen
I think the "jamming" of the gun may be caused by the bullets going off-screen without hitting anything, and since the player has 2 bullets that are recycled, he can't fire until they time out. I will check and fix this.
(You can maybe try to avoid this problem by not firing out a doorway?).
Edit: Seems ghosting may be caused by bad capacitor(s) in the Lynx.
-
Berzerkoids alpha 3a attached (just a fix to the flickering at the top of the screen on real hardware).
-
I like this version, the title screen is nice too. Updated screenshots over at Atari Gamer too (https://atarigamer.com/lynx/game/BefokBerzerkoids/265383336)
Thanks for updating this!
The online Lynx emulator on your site seems to work quite well.
Just one small thing - your description of Berzerkoids says "about 80%" complete. It's actually now around 99% complete.
-
Berzerkoids "alpha 3" attached. (Only tested in Handy)
Changes as per bhall's suggestions:
- Use inner or outer fire button to fire.
- Prompt to press any key to start on the title screen
- "Get ready" message before every level
- Level scrolls off the screen when you finish it.
- Slightly pulsating walls (it's quite subtle to avoid being too distracting).
Also a fix to the bullet colour (now always white).
Edit: attached file removed - see updated berzerkoids_alpha3a post below.
- 2
-
Here are some ideas…
- Allow both A & B buttons to act as fire button (unless you plan to use the B button for something else later on?)
- Something on title/splash screen to tell you to press a button or move to start the game
- Scrolling the play field as you move from room to room would be nice
- Is it possible to play the sampled sounds async? (Or are you doing it sync on purpose?)
- This wasn’t in the original, but the comment about not knowing the walls would kill you… Is it possible to color cycle animate the walls? (Does Lynx support indirection like that? like 4/800 did?)
Thanks for the suggestions, they are all do-able.
The voice samples will stay as they are (freezes while playing them back), as in the original. Also it makes it more dramatic
I will see what I can do within the next week or two...
PS: It's "Berzerkoids"
-
Sorry, may bad for not testing it on real hardware.
Seems that the Lynx does not like my "raw text printing" routine, so I have removed it an updated the download in post #16 above. Please re-download and try again.
Picked up some other issues on real hardware (screen refresh/vsync, sound glitches, bullet visibility).
Thanks for trying it
-
It isnt working for me on my sd v2 software, i get the intro sound and the title then it goes away and that is all i got.
Thanks for the feedback - I'll check it out.
- 1
-
Here is the latest (and maybe final) version of Berzerkoids for Lynx.
I have only tested on Handy so far, still have to test with my RetroHQ Lynx SD card.
Main changes are some minor speed improvements, and some voice samples.
Edit: Replaced the attached version with one that works on real hardware.
-
From my one test on Handy vs real hardware, seems the real hardware is faster:
http://atariage.com/forums/topic/272753-clearing-collision-buffer/?do=findComment&comment=3910354
(For this case at least - draw background clear sprite and draw full screen sprite).
Discuss 4TTUDE by Nop90
in 30th Birthday Programming Competition Games
Posted
Very impressive looking version of 3D Tic Tac Toe. Also cool chiptune style music
On my Lynx II (original screen) the gfx look a little tiny, very difficult for me to read the text. Maybe the grids should take up more space on the screen. (Also note my eyes are not good).