jenergy

You have a P.M.

Can you send me or share your ini file? You can find it in jzintvImGui folder in the root of your device SD

Really? On my device It started without any problem

Sent! Thank you

This is not completely true, I can have coins in a tile and a wall in next tile ?

You know, I think I found a reasonable solution, with a few trade-offs. Thanks to your suggestions/questions/conclusions, I found that my assumptions are wrong! Or better, they're no more needed. In particular: I don't need to create all the permutations, like I thought at the beginning. I don't need to reference more than 16 cards to describe the level. Why? Because I can think to model the level exactly how I do now (just walls and empty spaces). But just before rendering a particular block, I can refer to another map of enemies for that position, in order to understand if on that position there's something different than the 'standard' tile wall/empty, and in this case I can render the correct tile. As already reported, I just need to refresh background only when I scroll the screen, and I exactly know which tiles I have to update. Every time I need to draw a new column (or a new row), I can do this 'deviation' before rendering it. If this will have an effect with performance, we will see how to optimize it (with assembly maybe, as you suggested) So I can keep the same representation of the level than now, with the difference that I will construct it for the 'zoomout', and not as now for the zoomin. The zoomin will be easily deduced by the other one. Let's assume for the moment that I use a single grid-like pattern, like now. Considering the zoomout version, I need: 13 cards, for walls/empty permutations, as we already discussed. Lasers When you cross them while they're turned on, you die. We have trade-offs here The first trade-off is: I consider just pairs of widths. I need just 8 cards 0 1 2 3 4 5 6 7 LL OL OO LO LL WL WW LW OO OL LL LO WW WL LL LW Where L= Laser O= Empty W=Wall This implies that I cannot have lasers with odd width. And this imples the second trade-off: no coins or any other background stuff near a laser. But I can have potentially coins in the same position of lasers, because as you wrote me, I can swap cards when they are turned off ? I forgot to say you that laser must be red (or similar). This means that my two colors are blue and red. I can think to transform near walls in red (you know, the heat diffusion ? ) Exploding traps They're turned off. When you cross them, you trigger an explosion after one second. Same trade-offs, I consider just pairs of traps. I need just 8 cards TT OT OO TO TT WT WW TW OO OT TT TO WW WT TT TW Where T= Trap O= Empty W=Wall No coins inside or near an exploding trap, and no other background stuff near. For the explosion animation, I can reuse the laser ones ? Square of the dead Same behaviour than lasers. I can re-use the same cards of laser, and 2 more : For positions: NE-E -> I can use laser card 3 SW-S -> I can use laser card 4 W-NW-N -> I need a new card SE -> I need a new card Coins 13 cards for the coins to collect Here there's the most great trade-off: No coins near walls ? That's because, if we consider the thirteen tiles standard wall/empty, I can replace walls spaces with coin, or empty spaces with coins. Otherwise, I'll have to create all possible permutations Materializable wall When you cross them, they become solid wall. It's always 'lonely', just 1 card for it (I will model level conveniently). trade-off: no coins and no other background stuff near inside or near materializable wall. Once you cross it, it becomes one of the 13 cards of the walls Teleport (no gif here ? ) When you reach them, you're teleported in another position Same trade-offs.. 1 card, it's lonely, I will model level conveniently and no coins and no other background stuff near teleport And then, for the ZoomIn version 1 card for wall 1 card for laser 1 card for coin 1 card for exploding trap 1 card for materializable wall 1 card for teleport And now, for sprites: 2 cards for main character 2 cards for electric bombs (the movement will be smoother than this one in the gif.. you can see the so called 'initial' rom I posted, to see it in action) 1 card for a collectable colored key (to transform particular walls to empty spaces) 1 card for another collectable bonus (like the brake) I can think to define them once, since I can use embedded hardware features in order to reduce the size of the sprites. If I missed something I can add other acceptable trade-offs. For example, I can avoid the teleport, or the square of the dead. If I didn't miss anything, the total is 58 cards. Maybe that's too much anyway. But I still have some cards to use, and I can use sprite also for enemies/hazards if I model my levels accordingly. For example: If I use 2 sprites for character, and only 2 "electric bombs" (which use 2 sprites each), I still have 2 sprites for special situations (a coin in a particular position, for example). So, If this is all correct, I don't need color stack mode, and I can say that if I model my level in an accurate way, I can have always 8 sprites active Yes. But coins also And, that's another good point. Try to see if what I wrote makes sense. Then I can think to model my levels in order to reduce the thirteen cards, and at the same time have a better look like yours Yes: lasers and square of the dead and exploding traps Uhm no, you need to know always if an enemy is there If what I wrote is correct, I think that I have to spend attention on how I model my levels, in order to have an acceptable (and not too much demanding) number of objects appearing simultaneously on the screen..or not? Or you can play it on Steam ? Thanks!

This is a potential limitation I already thought: theoretically you can have a coin (background) for example inside an 'exploding trap' (background): you can traverse that position to collect the coin, but you also trigger the bomb for exploding after a second. If you traverse again that position during explosion (half second) you die. This is valid also for other enemies I want to reproduce. But this can be avoided ? Maybe this is one of the needed trade-off to accept, and I will have to put coins only on empty spaces. But about enemies, you can have only one enemy on a position, with the exception of the 'sprite' enemies: they can overlap with other enemies, but there's no problem on this. Absolutely correct! And I already planned, in a second time, to render walls smoother like the original game, by adding more tiles (only for the ZoomIn Version). But I never thought about it as a possible semplification of how to represent the level! This can be another alternative to consider!! Yes. Or better, enemies that I want to reproduce are static: their positions will always be the same, they are never 'removed', but they appear and disappear at fixed intervals. Exploding Traps: see point 1 Laser: an horizontal or vertical line of contiguous enemies turns on for a second, then turns off for another second etc. If you traverse them while they're turned on, you die Square of dead: like laser, but composed by 8 blocks all around a single wall block Teleports: you can imagine ? In my plans, I want to add also other 'bonus', just like brakes and colored keys to use to 'open' some walls, but this is very ambitious. And, finally, the interesting object is the 'potential wall': it's an empty space that becomes wall when you traverse it. This is a fun part of the original game: if you traverse it, you automatically create a different path because it's no more empty but it's a wall! Avoiding implementing this can be another sad trade-off ? Only coins (and other bonus, if available) can disappear, leaving the space to an open path (or to an already present enemy, in agreement with the answer of the first point) Yes, that's the origin of all the bad things ? And as reported in old posts, with my actual representation of the level I can reference only 16 of them, so maybe another compact and performant structure must be invented. ? You are right! I forgot it! There was an example too in the set of examples of IntyBasic! Another alternative to consider I didn't think!! Another potential trade-off. One of the captivating things of the game is that you 'discover' enemies gradually through the levels, and once you discover them, you can have them in potentially all subsequent levels. In the last hard levels, you are face to face with all the enemies you 'discovered' in your journey. An alternative is to start defying this as a fixed value, and find an optimized way to represent all, depending on it. But another alternative can be to consider it as a variable..I mean, an 'unknown quantity' which can be deduced subsequently, after having found the best optimized way to represent all. I need some further thoughts on all of this. I'm really happy and glad and thankful for your contributions ?

Ah! You're right, one (or both) have scroll Yes, actually the logic layer is independent from the rendering layer. In other words,I can play even if nothing is rendered. That's an interesting alternative Thanks! I'm glad that you gave it a try The scrolling version you played is what I call the "Zoom In" version. All is simple in there, because I just had to declare an 8x8 bitmap: game_bitmaps_0: BITMAP "XXXXXXXX" ' 0 - Wall BITMAP "X......X" BITMAP "X......X" BITMAP "X......X" BITMAP "X......X" BITMAP "X......X" BITMAP "X......X" BITMAP "XXXXXXXX" This is what I mean with "statically coded block": declared and later loaded with DEFINE ? For the empty spaces I can simply use the value $0100 from the ROM, so I don't need to create a tile for it So all is easy: if you have the wall, render this defined tile, otherwise render from ROM $0100 (which is an empty 8x8 block). No issues here. Things become a little complicated if I want to see a larger window of the level (what I call "Zoom Out"). I have obviously to reduce size of everything, and we can say that what you see in a zone of the "Zoom In" version must be 'reduced' to the half in the "Zoom Out" version. So: an 8x8 zone corresponds to a 4x4 zone. Or, for convenience, we can say that a 16x16 zone must be reduced to a 8x8 zone. This is what I meant with 'reduce': four blocks 8x8 (which is a 16x16 zone) must be reduced ( better word is 'remapped'?) to a block 8x8. So I created all 13 possible tiles 8x8: WW WW (for example, the red square) WO WW (for example, yellow square) WW WO WW OW OW WW OO WW WO WO WW OO OW OW WO OO (ex: green square) OW OO (ex: purple square) OO OW OO WO I report only a couple of examples: game_bitmaps_1: BITMAP "XXXXXXXX" BITMAP "X..XX..X" BITMAP "X..XX..X" WW BITMAP "XXXXXXXX" OO BITMAP "........" BITMAP "........" BITMAP "........" BITMAP "........" BITMAP "XXXX...." BITMAP "X..X...." WO BITMAP "X..X...." WW BITMAP "XXXX...." BITMAP "XXXXXXXX" BITMAP "X..XX..X" BITMAP "X..XX..X" BITMAP "XXXXXXXX" BITMAP "XXXX...." BITMAP "X..X...." WO BITMAP "X..X...." OO BITMAP "XXXX...." BITMAP "........" BITMAP "........" BITMAP "........" BITMAP "........" This is what I meant with "all possible combinations wall-empty" If the game would be finished here, that would be acceptable, but the problem are the enemies (see below) The level is statically defined, but in the original game some 'empty' blocks are special : if you traverse them, thay become a wall. If things become complicated, I can avoid this. We can say that level is statically defined. The problem is here. If you play the non-scrolling rom, you can see some enemies. Thoose are the only enemies I want to render as sprite. This because: I don't want to limit the enemies. And I want to model my character with two sprites, maybe with different colours All the other enemies I want to implement are some kind of traps which comes out (and then disappear) in empty spaces. If you see the video I posted in the first post, that should be clear. So, I have to represent them as background, not as sprite. Same thing for coins: Every level has dozens of coins, they must be background. The 'sprite' enemies start in a pre-fixed position, and then they move with a predefined pattern. The 'background' enemies are fixed in a pre-fixed position, but they 'appear' and 'disappear' And this is the problem: if I only have Wall and Empty block, thirteen tiles are enough, because they cover all the permutations. But if I have Wall, Empty, Coin, Enemy 1, Enemy2 etc, it's impossible to have all the permutations. If things become complicated, I will have to limit, but it's not planned to limit them There are special entites 'fixed' (like teleports) and enemies which appear and disappear. If you see the video, it should be clear Thanks again!

I think that this is my answer!! I already use the DEFINE directive, at the beginning of the program, pointing to my static bitmaps..but you're saying that I can re-use it when I need, in order to overwrite the 'character set' GRAM tiles, and for doing it I can use a buffer that I can dinamically create. If this is true, this can be my way.. Yes but there's no scroll in pacman. I need to scroll screen, and the best way in this case is represent the level with the "repeat count" technique (explained in @nanochess book) Considering the level in the zoomin rom I posted, you're saying that the whole level can be stored in memory like this: This is human readable (you can see the level!) but it's very expensive in memory. XX and II are constants which represent 16bit variables, pointing to predefined 8x8 bitmap blocks. I actually represent the same level in memory like this instead: which means, for example for column 4 (0 based), 9 tiles of type 0 + 8 tiles of type 0 (= wall, statically coded) 2 tiles of type 1 (= empty, statically coded) 3 tiles of type 0 (=wall, statically coded) 4 tiles of type 1 (=empty, statically coded) etc.. This is less expensive (and I can reduce it more, since I'm lazy and I'm actually using '9' as max size instead of 'F' which is 15) and it's very useful when used in combination with the 'scroll' feature of IntyBasic, because by keeping a pointer to the last column rendered, if you scroll you are ready to keep the exact tiles you want to render. At this point, I can create something similar for the zoomout version, and dinamically create in memory my buffers for the GRAM, for using them later with DEFINE directive. If I can do it in the 'loading level' phase, all comes free, since I already implemented the scrolling feature. But I have to invent some kind of trick, because while for the big version for the moment I only need two kind of tiles (0=Wall and 1=Empty), in the zoomout version I need much more of them, and the limit with repeat count trick is 16 (from 0 to 'F' in hexadecimal). I have to check this too Thanks again!

Thanks, and thank you for your answer. And I'm very sorry for the questions I'm going to do ? This is what I didn't understand. Just suppose I want to change the first 8x8 cell of backtab: #Mcard= peek ($200) #Mcard= <manipulate it> poke($200,#Mcard) In the manipulation step, I cannot 'change' bits. With the exception of colors, I can only change a reference to an already statically defined memory block 8x8. So, I'm stucked, because I need to prefill all of them. Is this correct? This thing of an 8x8 buffer seems interesting..how can I do this? I mean: I don't need to update Backtab in every frame, I just need to update it only when the screen is scrolling, and I only need to update the first/last column/row, depending on the direction of scroll. The rest of the screen is automatically updated by the 'scroll' feature available in IntyBasic. So I can easily identify the exact 12 tiles to update (on horizontal scroll) or the 20 tiles to update (on vertical scroll) And..you said I can update GRAM, which for me is different than say I can update BackTab..how can I do this? I already cycle through pre-defined 8x8 bitmaps, you say I can cycle through 8x8 buffered blocks? Check screenshots: The left one is the zoomIn version..you can see some 16x16 (= 4 blocks 8x8) colored blocks..and on the right, in the zoomOut version, you can see the same blocks 'reduced' into 8x8 blocks In my previous post I added the zoomIn Version rom too, which is playable Thanks

Hi guys, I'm here to ask you some technical suggestions for my ambitious project, called "The Sentinel". My goal is to finish it and publish it (somewhen, somewhere, someway) as a paid (cheap ? ) product, if it will become nice. It wants to be a Cyber Protocol style game..that's a game I really like, I also reached the second place of the $1000 contest, and even if I never had my reward.....I still love it. About the game: you're inside a grid, think to pacman, but every level has a different grid, or better it's a little maze. You have to collect coins and you'll encounter different kind of enemies in your journey. The particularity of your character is that its velocity is very fast, and you cannot brake: when you choose a direction to go, only a wall or an enemy can stop you. Or better, this is what happens in the original game, while in "The Sentinel" you'll have some kind of brakes enabled.. See here a video of the gameplay of the game. I repeat, it's VERY ambitious, and I would have to fall down to a lot of trade-offs, but I want to try ? So, I started develop the logic, and here (rom and level map ) you can find the first implementation, which is WITHOUT SCROLL. Please don't judge me for the graphic, I'm just still working on the skeleton of the game.. The enemies here are rendered as sprites (MOB)...but this kind of enemy will be the only one used as MOB, all the other ones will be rendere as changing background. Think to "Space Armada" or "Frogger", but in my case they won't be moveable. The text file contains the map of the level. If you open it with notepad++, by double clicking on a 'II' (or on a 'XX') you can see the maze. And about all this, thanks to @nanochess for his book ? If you run the game (no coins yet. ? ), in the left-up part of the screen you can see some dots moving: that's the real logic of the game, a virtual 32x32 grid where every position is a pixel. I then render every position and sprite with the classic 8x8 bitmap related data. Of course, not the whole grid can be visible, without scrolling. So I then created the scroll logic (on 8 directions), where the "camera" (sorry for using this word related to a futuristic concept ?) follows the character, which can move everywhere in the grid. You can find them here (rom and level map) And now it comes the problem, related to the 159x96 pixel screen and its obvious limitations.. I want to reproduce the 'fun' of the original game, but if a level is tricky, a continuous scroll I think would be annoying, and would generate some headaches too. So, exactly as the original game, I started to develop a kind of zoom-out, by reducing all sizes. Here is the result (it's just visible, not playable) of the now_became 48x48 grid: (rom and level map) As you can see, the level is 'shorter'. And now come the technical suggestions I need. In order to zoom-out the level, I've taken a square of four continuous blocks of the level, and statically coded the 8x8 resulting block: |--------|--------| |--------| | 8x8 | 8x8 | |8x8 | | Wall | Wall | |Miniwall| | | | | | | | | | | |--------|--------| --> |--------| | | | | 8x8 | 8x8 | | Wall | Wall | | | | |--------|--------| |--------|--------| |--------| | 8x8 | 8x8 | |8x8 | | Empty | Wall | |Halfwall| | | | | 1 | | | | | | |--------|--------| --> |--------| | | | | 8x8 | 8x8 | | Empty | Wall | | | | |--------|--------| |--------|--------| |--------| | 8x8 | 8x8 | |8x8 | | Wall | Empty | |Halfwall| | | | | 2 | | | | | | |--------|--------| --> |--------| | | | | 8x8 | 8x8 | | Wall | Empty | | | | |--------|--------| Etc... I created all the possible combinations Wall-Empty, by coding statically the 8x8 bitmap representations for GRAM. This is obviously the wrong way, because it's unthinkable to statically create ALL the combinations Wall-Empy-Enemy1-Enemy2-Enemy3.., since enemies (and coins) will be like walls. But I had a (fake) ace in the hole, thinking that there was no problem on this: I thougth that there was no need to create every single combination, since with PEEK and POKE I could change dinamically every single pixel in a 8x8 tile of a rendered backtab. And I was wrong.. you can only change the whole 16bit pointer variable, which means that I can simply dinamically switch to another predefined 8x8 bitmap in GRAM..is this right? So..my questions: 1) Can I dinamically change the pixel content (0 to 1 or viceversa) of an 8x8 tile on the screen (not with peek/poke but maybe with other directives)? Maybe not ? 2) Instead of a static way, is there a dynamic way for create my 8x8 bitmap to load? 3) If answer 2 is yes: lot of 8x8 bitmaps would be genereated, so in order to avoid to full the memory, can I unload some already-loaded 8x8 bitmaps from GRAM? 4) Do you see another way to 'reduce' four 8x8 blocks into one? Thank you EDIT: Added also the "Zoomin version" level_0_initial.bas level_0_scroll.bas level_0_zoomout.bas theSentinel_initial.rom theSentinel_scroll.rom theSentinel_zoomout.rom theSentinel_zoomin.rom

I can confirm: It works perfectly!! Thanks @larryvgs!

Two for me! Thanks

For Windows users only: here you can find a new unofficial version, containing the 'Break' key bugfix (unable to pause the game) and now you can select an launch an external jzIntv, if you need to use frontend for launch different versions of jzIntv than the embedded one (which is the latest SDL2 version with some minor changes). This is useful for example if you need to launch SDL1 version, for some reason. External jzintv.exe (case insensitive) must be placed in the same folder of main executable Thanks to @larryvgs for reporting, suggestions and tests!! P.S: It's still unofficial because I need to create executable for Linux also, and maybe to fix other little things before create a new official release.

If I well remember, I just replaced the 'border' screen with black in jzintvImGui. Can you give it a try? https://github.com/jenergy/jzIntvImGui/releases/download/2.3.2/jzIntvImGui_2.3.2.zip

Hi @mrb55, to play with jzIntv you also need two main bios files, "exec.bin" and "grom.bin", jzIntvImGui searches for them in roms folder. See :

I just tried the 1.2 version on the Nintendo Switch and it's very good! I also tried DK1 arcade and seems to be ok. The only 'strange' thing for the moment I've found is the intro music of lock 'n' chase, where there's a little noise. Instead, audio seems ok while playing FreeIntv - Lock'n' chase.mp4

Purchased!

It works perfectly. Wonderful ? Thank you very much

Congratulations and thanks! P.S "Ha Ha Ha Na" is a kind of easter egg? ?

As @llabnip wrote, it's a normal standard Nintendo Switch which has been hacked. When you hack it, you can install on it also custom programs, and I could not avoid to port jzIntv on it. Since it's not globally considered a 'clean' action, maybe it's better to not publicly explain and post here how to do it, but that's just my opinion ?

I ported jzIntv on the switch: If you have a modded switch (please don't ask..) here you can find the homebrew: https://github.com/jenergy/jzIntvImGui/tree/Nintendo_Switch

Not in the 8K version

Hi, one of the difference between LNC 6K and LNC 8K is that in 6K 'Lupin' can brake, while in the 8K version he can't. But is this really true? ? There's a position where he can brake, in particular situations. Who can find it? ?

Hi, finally I've put the whole project on GitHub. You can find it here, if you want to contribute or to take a look at the code. If you just want binaries, here is your place. There's the 2.2.6 version now, for Windows, Linux and Android. Thanks again to @Zendocon for his PRECIOUS support. Have fun!