Added some new stuff to my wip, and optimized a lot to support bigger levels, more enemies... It worked great with kega fusion, gens, mess... Then tried on real hardware and boom! Unexplainable screen tearing, video memory corruption, freezes, spontaneous resets. Very hard to track. Now working hard to make it stable again.
Nice done for this ! Conceal the glitch, do you have a screenshot with artefact ? Perhaps VRAM corruption, you overwrite on a already adress, too many sprite on same line/column, etc ... It's a HARD way to debug correctly a game on Real Hardware. Good luck !
I got this error message when it glitched. I think it came from mess:
process 11516: Array or variant type wasn't expecting any more values to be written into it, but a value object_path was written. The overall signature expected here was '��' and we are on byte 34 of that signature.
Not sure if it's a bug in mess or in my program.
Last Edit: Sept 18, 2016 19:00:51 GMT -5 by landeel
Can now handle virtually unlimited number of objects in the level. But I will limit it to around 80 to avoid slowdowns. No more glitches, no longer losing sprites. Looks stable to me, but of course, it needs more testing.
Well, the code is like 99% complete. I have rewritten part of the object handling/enemy AI code and separated every enemy/object type into its own sub. I still have plans to implement more enemy/object types, but it will be much easier to do now things are organized. I have 5 full playable levels already, mostly imported from the PC version, but very improved. Unlike the PC version, every level has its own tileset and different types of enemies. The final release will have 8~9 levels. Doesn't sound like much, but anyone who played the demo already knows levels are huge and take a long time to beat. The game will support SRAM to save the progress, it's already implemented. Still a lot of drawing to do.
If you want to start a big project in BasiEgaXorz, I wanted to share with you a few things I've learned:
1) Real hardware is way more sensitive to glitches than emulators.
2) Never use FREESPRITE. It always glitches in the real hardware, no matter what you do. Hide and recycle your sprites.
3) Stay away from SPRITEPOSX/Y. Use variables to store sprite positions.
4) Division by 2 is buggy (/2). Use bitwise operations instead (>>1).
5) BEX can't really do signed integers. -1 will become 65535.
6) Don't create a loop with VALT as your main routine. It doesn't work well. Use ON VBLANK GOSUB.
7) Separate all the rendering from the game logic. Do all the rendering at the beginning of your main loop, specially sprites. Don't let the rendering slip out of the VBLANK period.
8) Don't use too many sprites in the screen at the same time, and don't change them outside the VBLANK period. It's not safe and may cause glitches. There are unexplored bugs in this area.
9) SELECT CASE is useful, but it doesn't work like it does in other basic languages.
10) In SELECT CASE, you can't use CASEs with #constants.
11) You can't DIM an array using #constants.
12) If you use SRAM, use only ODD bytes. The OPTION EXTERNALSRAM flag is not enough. You will have to code it yourself.
13) Avoid multiplications, divisions and complex mathematic operations in your main routine. They are slow. Try to "cache" the values when it's possible.
14) Your code can be huge, but try to execute as little as you can in the main loop. For example, some tasks can be run once every 2 or 3 frames. Alternate tasks.
15) You can use a soft reset to return to title screen. (asm "jmp __start") or (asm "jmp $200"). This will reset all variables.
16) Don't redraw the entire scroll. Only draw parts that need to change.
Last Edit: Sept 28, 2016 12:25:01 GMT -5 by landeel
Hey Congrats for finalize your nice project !! All things you're learned, I learn on my own on my first project "Papi Commando" ! But, don't know the Jmp $200 tips who reset the variable .. Even the Global variable ? Great job !
The jmp just jumps to the init section of the code, it's not a true soft reset. You can alternatively place a label at the start of your code and jump to that with a Goto command.
Also, freesprite shouldn't be bugged. I've never had any issues with it. Can you post an example where it breaks?
The jmp technique resets everything, goto doesn't. It depends on what you want to do.
The thing with freesprite is that sometimes it glitches when it's executed after the vblank period. Looks VDP related because the graphics get all scrambled and the video mode changes. Sometimes it just freezes or resets. It doesn't happen with emulators, only in the real hardware. Tried with my two different model 1 consoles, one is an american Sega Genesis, the other is a brazilian Mega Drive. Same problem. But it doesn't happen every time, seems very random.
Right, I'm saying the jmp only goes to a user routine; it's not a true soft reset, so you can do a goto to your own routine (especially if you don't want your game to reset a high score).
Also, I've programmed over a dozen games in Bex (sizeable ones, not just small projects) and haven't had any issues with it on the model 1 (with and without tmss), model 2's, model 3, and the cdx without any issues, which is why I asked to see the code that's having issues, as it's 99% of the time related to bad coding habits.
Too many people claim bugs that aren't bugs and stems from either a lack of knowledge, or bad coding practices.
-Six levels complete, including graphics; -All enemy types implemented except for the last boss; -Many gameplay, physics and aesthetic fixes; -Implemented a few cheat codes, including level select and debug mode; -Added a small intro story screen; -All text translated to brazilian portuguese and language option added; -Continue works even without SRAM, while you keep the console on; -Pause and hold A+B+C to suicide or hold B to turn music on/off.
To do: -3 more levels; -last boss; -ending sequence; -draw missing level, backdrop and enemy graphics.