itch.io

👍

Stand by for APIS and Cosmic Galaxy releases in the next few days hopefully!

Glad to hear that thanks, if you’d like to see any changes or additions to the game just let me know. How do you find the difficulty?

Wahoo! Got there in the end! 🤣

Wahoo!

v2.0.2 just uploaded, along with Dev changelog! I was going to suggest you beta test my next releases due to your very keen eye, but fear I may not progress with them due to you finding lots of issues 🤣

v2.0.1 posted, hopefully this fixes that one liner! If you`d like to see any other changes or additions to the game just let me know!

Try V2.0 and see uf that fixes it, fingers crossed!

Scratch that just working on another fix

V1.10 just uploaded, details on the Devlog, let me know if this fixes it this time !

1.9 just uploaded, any better this time?

I will apply this fix on Wednesday when my Claude tokens refresh since I burned through my usage on 2 x new games I have one the go! 

We need to fix an architectural coordinate mismatch in BeeNext.

As shown in our recent test builds and screenshots, the Layer 2 background art, tilemap, and copper effects render correctly across the full 320x256 screen. However, the game logic, enemy spawn paths, player movement bounds, and collision checks are still trapped inside a centered 256x192 logical box. This creates an unwanted 32-pixel dead-zone border on all four sides where enemies spawn late, bullets stop short, and the player cannot reach.

I need you to refactor the game engine to run natively across the full 320x256 display space (accounting for the top score HUD). Here is the technical roadmap to fix this once and for all:

1. Expand the Core Coordinate System:

- Shift the internal playfield coordinate bounds from the legacy 256x192 limits out to full 320x256 resolution.

- Adjust the coordinate offset mapping so that logical (0,0) aligns with the top-left of the physical 320x256 screen (minus the top status bar height).

2. Update Player & Entity Boundaries:

- Recalculate player movement clamping so the bee can travel right out to the true edges of the 320-pixel width and 256-pixel height (leaving just a safe 8-16px sprite clipping buffer so hardware sprites don't half-cut off).

- Update all enemy spawn vectors and entry coordinates so that enemies originate from off-screen or the absolute outer boundaries of the 320x256 window rather than popping in 32 pixels inward.

- Ensure all bullets, bombs, options, and pickups map correctly to this expanded coordinate grid.

3. Hardware Sprite & Display Registers:

- Audit and update any Next hardware sprite clipping or display window registers (NextRegs) to ensure hardware sprites are fully permitted to roam and render out in the outer 32-pixel margins without being artificially clipped.

Let's trace through our movement limits, boundary constants, entity spawn routines, and hardware register configurations to implement a true edge-to-edge 320x256 build.

Thanks I’ll copy this to Claude and see what’s suggested 👍

Does the latest update make much difference?

Claude said….

Your player has a point, and I think it's worth fixing.

Here's why it happens. The game's logic works in a 256-pixel-wide space: enemy flight paths, bullets, the bosses (drawn on the 256-wide Layer 2) and the bee's movement limits all use it. The screen is 320 pixels wide, so there's a 32-pixel strip on each side that the bee can't enter. That's a fifth of the width. Before v1.7 it didn't stand out, because the play area looked boxed in anyway. Since v1.7 the ground scrolls edge to edge, so those strips look like playfield, and hitting an invisible wall there feels like a bug rather than a design choice. In the arcade TwinBee you can fly right to the edges, so most players will expect that.

The catch is balance. If the bee can reach the edges but enemies and bullets don't, the edges become safe spots where you can sit and dodge everything. So there are two honest ways to fix it.

Open it up (my recommendation). Let the bee fly to within a few pixels of each edge. Then make sure the edges aren't free:

• aimed bullets already track the bee wherever it is;
• I'd widen a few enemy paths, mirroring some of the swoops so they cover the outer strips;
• bells and power-ups would be allowed to drift wider too, so collecting them there feels natural.

It's a moderate change, because the bee's position has to move from the 256-wide range to the 320-wide one: shots, collisions, Options and the ice sliding in World 5 all use it. It's well within reach, and I can test it in all five worlds and on the bosses.

Make the edge look intentional. Keep the play area as it is, but mark the side strips visually, for example with darker, framed or hatched edge columns. That way the boundary reads as a wall rather than an invisible barrier. It's cheap and changes nothing about balance, but it gives back some of the full-screen feel v1.7 was going for.

I'd go with the first option. The game will feel more like TwinBee and less cramped, and the balance risk can be managed. Shall I build it as v1.8?

I appreciate it and the feedback, I can rework it if you feel it would be beneficial to gameplay, if anything else needs tweaking just let me know and thank you for introducing me to Zed-Next ☺️

I appreciate it and the feedback, I can rework it if you feel it would be beneficial to gameplay, if anything else needs tweaking just let me know and thank you for introducing me to Zed-Next ☺️

are you reffering to a margin on the left and right sides? its the same with the other emulators ive tried on Windows, does it affect gameplay do you think snd would you rather have movement right to the edge on the left and right sides?

yes, not tried Zed-Nex before, so just tried it, tbh, its the sme with Zesarux and Jnext in that there is a portion to the left and right hand side that you cannot enter.  Do you think you should be able to move edge to edge? does it affect gameplay?

is there a bug?

Your welcome!

Thank you :-)

not tried under Cspect, only MiSTer, Zesarux and Jnext, but full screen under those...

Me too! - Thanks for giving it a try!

Yep, Thank you 👍

https://roman126.itch.io/leaping-jack

My apologies, hashtag removed 

Got a new version releasing soon if you want to port, Claude had a data loss and I never backed anything up (you learn the hard way), so started again with much better version!

Claude says...... Yes, that’s a real bug, not an emulator quirk. In the current code a shark starts chasing whenever you’re within about 110 pixels horizontally and 36 pixels vertically. It doesn’t check whether there’s rock between you, and it never gives up. When rock blocks it, it turns around for one frame, then turns straight back towards you, so it hovers at the wall. Its chase speed is also too high: 1.5 px/frame in round 1, which matches the diver’s top speed, and 2.5 px/frame from round 2 on, which is faster. I’ll fix all three.

• They could “see” through rock. A shark started chasing whenever you were within range, even with a wall between you. Now it checks for a clear line through the water first. If there’s rock in the way it loses interest, turns away and swims off for about 4 seconds before it will look for you again.
• They never gave up. A chase now lasts about 4 seconds at most. A shark also gives up straight away if rock blocks its path, instead of hovering at the wall.
• They were too fast. A chasing shark moved at your top speed in the first round and well above it from round 2. It now swims at 1.25 pixels a frame in round 1 and 1.5 from round 2, against your 1.5 at full speed. In open water you can always pull away.

Thanks for making the video, I’ll add to the page if that’s OK?  If you can think of any improvements or additions to the gameplay just let me know!

thanks for reporting this, I’ll take a look and get Claude to take a look. I’m waiting for my Claude reset on Wednesday as half way through a night upgrade on Scuba Dive, Claude built for 1MB Ram so I’m applying a 2MB update. I did query the pulse myself and I think I’ll go for a slow recharge of 1 pulse every 20–30 seconds. You should see an update later in the week!

Thanks, Sure please go ahead. I have another version in the works as the was some Ssndbox issue that caused  Claude to lose the code so started again! Send me a link so I can try it out!