I'm going to quote myself from another topic about this recently because I think this is the fastest and easiest technique to create multiplayer games:
Quote from: quigibo
Like I always say, linking is easy, but syncing is hard. Puyo Puyo runs fast because it only needs to send data when a particular "event" occurs (combos). Event driven programming style is a little different than what you're used to but basically you put the Get() in your main loop so its always ready to receive an event. Don't forget, Get() doesn't delay or wait unless the other calc is sending something.
You send data by first sending an enumerated event type (1 bytes) followed by the event data (which may be different length depending on the event). For instance you might need to send a character's position. This can be done by sending a "X change" event followed by the x coordinate whenever that coordinate changes and a "Y change" event followed by a y coordinate. The actual transfer speed is about 500 bytes per second maybe. If your main loop is running at 30fps and don't mind reducing to 20fps that's about 8 bytes per frame of data you can send which is probably enough for a decent subsets of multiplayer games.
By the way, I assume you are trying to make a method to access the nth string correct? This can be done fairly easily by using the [00] terminating character for strings. The string that comes before the Nth [00] is the Nth string. So suppose you had this:
Also, I still get random errors that occur some of the time in my programs, including randomly failing to assimilate pictures into programs correctly.
Are you importing the pictures as tilemaps by any chance? Because there might still be a problem with that feature 1% of the time. Also, does recompiling fix the issue?
I'd love to add that but my own error scrolling isn't working yet and I feel I should at least fix that before adding a zstart entry call. Maybe you can help me, I don't know what I'm doing wrong because I'm still not exactly sure how the OS handles edit buffers entirely. It appears to work when instant-scrolling in small programs, but it RAM clears sometimes when scrolling to a spot greater than 8kb into the code. Its somewhat random and not completely consistent. How did you do it in zstart? Do you see anything wrong? This is the code I'm using:
Spoiler For Spoiler:
EditorExit: ld a,(v_PrgmStartPage) or a jp nz,SystemExit ld hl,v_InputName+1 ld de,progToEdit ld bc,8 ldir xor a ld (de),a ld a,kPrgmEd B_CALL(_NewContext) ld hl,(v_PrgmPtr) ld bc,(v_PrgmStart) or a sbc hl,bc ld b,h ld c,l ld hl,(editTail) add hl,bc ld (editTail),hl ld hl,(editTop) add hl,bc ld (editCursor),hl ld hl,0 push hl EditorLoop: ;Check if at beginning of program ld de,(editTop) or a sbc hl,de jr z,EditorFound B_CALL(_BufLeft) ld hl,(editCursor) ld a,(hl) cp tEnter jr z,EditorFound pop hl inc hl push hl jr EditorLoop EditorFound: B_CALL(_BufRight) B_CALL(_DispEOW) pop hl ld a,h or l jr z,EditorMon EditorScroll: dec hl ld a,h or l jr z,EditorMon push hl B_CALL(_CursorRight) pop hl jr EditorScroll EditorMon: res 2,(iy+50) res 7,(iy+20) res 3,(iy+5) B_JUMP(_Mon)
Assuming you're talking about the OS's Pic0-Pic9 and not an Axe pointer name, yes they are the same from a coding perspective. To the OS, they are a little different though. When the OS sees a Pic1 it assumes its a picture and will let you use all those BASIC commands on it. When you use an appvar, the OS will not really let you do much to them and the only place you will see them is in the memory management screen. Also, appvars will take up more room in RAM since they also have names which are up to 8 characters long.
But yeah, other than that, you can store data to anything and use it just the same: appvars, pics, strings, lists, even the OS vars. But the best option for regular data is probably the appvar because its invisible to the end user and can't be deleted accidentally unlike a pic or string for instance which will get overridden constantly by BASIC programs.
Is there a particular reason you want to use Axe instead of BASIC? Converting a program doesn't make it any "better" unless you are planning to add features that are otherwise impossible to do in BASIC. Also, the Axe language is specifically designed for games and has many common routines and functions for this purpose. But, it leaves out a lot of other things such as high precision math and advanced string manipulation which are uncommon in games, but might be necessary in a BASIC program.
So I only recommend switching to Axe if you're specifically trying to build games.
Hmm... I guess that's true. I'm using the exact same type of optimization for the new bitmap command (which technically you can think of as a 1x1 smooth scrolling tile mapper, and it can actually be easily used for this purpose ). Its just that although the routine will be insanely fast, maybe up to a 2 times speed up, it will also be insanely large. Just the subroutine of the bitmap command is already 210 bytes and the tilemapper would end up at least that size I'm sure.
Thinking about this again, I might make this an offical included Axiom like Memkit because then it could include multiple versions, convenient tokens, and use the Axiom variables for optimization...
First of all, I have been very busy recently so I've had much less time to work on this than in the past. But the good news is I'm about to have a week off before finals so I'm going to make a promise to release "what I have" by then. I've fixed almost every bug reported so far and added some new features, both requested, and some I think everyone will find useful. So expect either 1.1 or 1.0.6 by no later than Dec. 9 depending on how many more things I add.
Second, I've always wanted to include a tilemapper in the language, at least for rendering and collision detection. Unfortunately, the reason I haven't added this yet is because tilemapping is so specific to games it would be impossible to find one 'universal' solution for everyone's application. With every extra 'feature' added to a tilemapper, it just makes it larger and slower which you might not want if you just need something simple and fast.
But now I've decided, why not just ask? What I want to know is how useful some commands for this would be if you had to have just one routine. Would you actually use it or would you be required to write one yourself because you need something faster or with more features? So I'm going to compile a list of features in order from smallest/fastest to biggest/slowest. I want to know what you use in your current games right now, and what you would plan on using in the future. Let me know the name/names of your Axe games or even assembly game if you happen to be an asm programmer because the same principals apply.
Tiles: Byte tiles (256 tiles per set, 1 byte per tile) Nibble tiles (16 tiles per set, .5 bytes per tile) Compressed tiles (Some type of RLE or something)
Scrolling: Static (no scrolling) Block (scroll one tile at a time) Smooth (scroll one pixel at a time)
Buffer: Restrict to buffer (~760 bytes max) Any RAM location (~4000 bytes max realistically) Any File location (~24000 bytes max)
Obviously I can't just make a compressed 4 color grayscale smooth scrolling tilemapper with custom sized sprites read from archive because it would be very slow, a pain to initialize, huge, and take forever to code. There are some compromises I can make however, such as Monochrome drawing to a specifiable buffer, meaning you can have 2 tile sets and draw them once to each buffer if you need grayscale, but this is a slightly inconvenient representation for sprites because you have to separate the gray layers into different data sections. So anyway, lets just say if you had to choose some even distribution of features, what would they be? And would/could you use this configuration in your current games?
Another thing to keep in mind is that because a majority of the time spent rendering a tilemap is sprite drawing and not the tilemapping itself, any speed increase from this routine will be very tiny compared to if you wrote it in native Axe. Most of the advantage will come from reduced size of code and simplicity of the programming.
My personal preferences are: Nibbles, Smooth, RAM, Monochrome, 8x8
Yeah. Nearly every programming language uses (Y,X) and every spreadsheet and math program uses (X,Y). So I think I'll end up sticking with X,Y just because it optimizes better, and its more consistent with the rest of the Axe syntax when looked at independently of other programming languages. Iambian used this convention as well.
Yeah, mine is lossy, but its very compact and tiny. The most I have seen it off is by 4 binary degrees but on average its usually less than 3. It is exact every 45 degrees. This is the routine I'm using:
The drawing commands are hardwired to the main buffer for extra efficiency and size optimization. You should plan out your buffers so that the one that requires the most drawing to is the main buffer (which is not always the black layer). Then use the appropriate DispGraph command to display it.
Show Posts
). Its just that although the routine will be insanely fast, maybe up to a 2 times speed up, it will also be insanely large. Just the subroutine of the bitmap command is already 210 bytes and the tilemapper would end up at least that size I'm sure.