Yeah I updated DrawString to restore the string in Ans when it returns .. I think this was in DCSE8.1 ... it's in this version definitely however.

So will this be 2 of the last 3 consoles where a zelda game has rolled over to the next console instead of it's original platform?

Also the NX must, I repeat ***MUST*** be significantly more graphically capable than current options otherwise it WILL BE Nintendo's last home console.

Some people take gameplay over graphics.
Some people take graphics over gameplay.

But Nintendo have ALWAYS already had the gameplay so they need to have the graphics as well.

My fear however is that they will try to 'not compete by going their own direction' which will be there undoing ... it's too soon to pull another 'Wii' and even then after the MASSIVE lead the Wii had early on, the lack of mainstream games enabled both competitors to finish up within 85% of their sales anyway.

Nintendo are the greatest but they must adapt. The Wii U is a great console but everything from its specs to it's release window tell you that Nintendo don't want to compete with sony/ms and would rather be seen as a complete alternative. I do however believe that naming it the 'Wii U' is what ultimately caused it's commercial failure as even members of my own family thought the 'Wii U' was nothing more than a new controller for the Wii.

That being said, I am excited to see what the future holds!

I'm not entirely sure however there is a strong focus for myself on getting CE related stuff released .

Also I fixed a bug in the DrawString command which can be seen with the extra character in the xMEME example - hopefully it's good now.

I have another bug where some tilemap data gets overwritten that I am investigating now.

I'm very glad that I have 4 days off over easter and am hoping to knock off a few more functions .

Looks very nice Mateo.

The compression is a nice touch. I had experimented with lz77, huffman and pucrunch in the early days of the CSE.

Will you be providing decompression routines for users as well (if not so already)?

DCSE will perform hook chaining so there shouldn't be much of an issue.

The frames functionality was actually written for the CSE first however it hasnt been released. It will depend if there is an update to DCSE8 I suppose.

At this stage I haven't 100% locked down the location of the hook stub itself but the routines will be run from a standard location. There are a number of areas in RAM that can be useful for storing hooks as well.

This may change over the life of XLIBCE however the end user shouldn't notice.

Unfortunately monochrome projects won't work out of the box, however they can be ported with graphics updates and such.

I have been working on porting over xLIBC to the CE and after a slow start have been making some good progress of late.

At this stage I have a number of routines for tilemaps, sprites, images, key input, drawing strings and such already ported, along with support routines for collision detection and map checks etc.

There have been some nice speed improvements with the CE version even in the current unoptimised state (working on functionality first).

Here is a tilemap scrolling test:
TI-84+CSE:

TI-84+CE:


And this morning I ported over the BGPIC & BGPIC32 functions as seen below:



I should have noted that this is the CSE xMEME example program running completely unaltered.

I have implemented 'frames' for both BGPIC's and BGPIC32 images so that you can store multiple images in a single appvar. Here is a speed test between the CSE and the CE:
CSE

CE


I have also ported enough routines so that the xZELDA demo works in fully. Note that this program is unaltered from the CSE version:

What kind of games do you play?

Quote from: Dudeman313 on March 03, 2016, 10:31:17 PM
As for incomplete projects, there's always @tr1p1ea 's sadly lost Super Mario and the Elemental Crystal, and that one Mario game on MaxCoderz that never got finished either.
The source and game can be found here.

yes very sad .

There is a small old (and possibly buggy) demo of the Mario game here ... a shame that it doesnt have much in it :S:

http://tr1p1ea.net/files/downloads/Mario_tr1p1ea.8xk

20 years, wow that's pretty impressive ... still going strong!

Also we need a calc version!

This might be possible on the CE, even in actual 3D ... but that would take a little work.

I don't see why some of those games couldnt work.

Yeah it takes a bit of getting used to, especially to make the first jump - but after that you should be good .

Recently I have been very busy IRL and unfortunately haven't had a lot of time to dedicate to coding and stuff. I have finally set up my workstation at my new house and decided to work on a couple of Unity kits which can be turned-around quite quickly.

I have a couple of puzzle games that are basically Minecraft themed from a graphics perspective (while I continue to work on my own Minecraft/Cubeworld game: http://www.cemetech.net/forum/viewtopic.php?t=11718)

Swipe Craft:
http://play.google.com/store/apps/details?id=com.tr1p1ea.swipe.craft.free


Jump Craft:
http://play.google.com/store/apps/details?id=com.tr1p1ea.jump.craft.free


Nothing crazy and these are pretty much just repacks but it's good to be getting back into the swing of things again.

Drawing logic is either LD(direct load) or one of the bitwise AND,OR,XOR.

LD = Write entire sprite to buffer, including background (will show up as a square)
AND = bitwise AND the sprite with the buffer (can be used for sprite masks)
OR = bitwise OR the sprite with the buffer (likely the most common option)
XOR = bitwise XOR the sprite with the buffer (probably as common as OR, can be used to erase previous sprites as well)

Normally people would use OR/XOR when drawing sprites.

I was wondering how you were coming to the conclusion regarding HL=$0000? Are you using a debugger (which emulator if so)?

Also do you utilise any interrupts in your program?

I'd be happy to take a look for you.

(Also love Yatzee ).